Whenever I run a command in a command prompt window, I can see what's happening as it does. However, upon completion it the window resets to basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.
TIA
On 02/04/2024 12:26, John C. wrote:
Whenever I run a command in a command prompt window, I can see what'sI have also never had that problem in Windows 8, 10 or 11.
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.
TIA
What command(s) are you running?
What command(s) are you running?
Whenever I run a command in a command prompt window, I can see what's happening as it does. However, upon completion it the window resets
to basically a clear screen so that I'm unable to see what was done.
Can anybody tell me how to stop it from doing this? I never had this
problem in Windows 7.
John C. wrote:
I have also never had that problem in Windows 8, 10 or 11.
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.
TIA
What command(s) are you running?
John C. wrote:
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.
TIA
Put your command in a bat file and follow one or more lines of the bat
file with
Pause
exit /b
Maybe you don't need the pause, I can't rememeber, but it doesn't hurt.
If it's the same command that you run over and over, you can have a
dedicated bat file, but if you don't want to have one each, you can make
a bat file with a parameter, which would be the ccommand you are going
to run at the moment. I'm not sure anymore how to do that but iirc you
would type:
Go (or whatever you called it) [command]
and the first line of the bat file would include %1, which would then be filled in with the command.
When the command line windows does that CLS thing after this command and >parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
I still use an ancient freeware command line program called "XXCopy" to
clone folders from one drive or partition to another drive or partition.
Eg. (slightly modified for privacy) a shortcut with this target:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone /YY
When the command line windows does that CLS thing after this command and parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
"John C." <r9jmg0@yahoo.com> wrote:
I still use an ancient freeware command line program called "XXCopy" to
clone folders from one drive or partition to another drive or partition.
Eg. (slightly modified for privacy) a shortcut with this target:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe
"C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone /YY
When the command line windows does that CLS thing after this command and
parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
Do you know XXcopy (abandonware) will run under Windows 10? Open a
command shell (cmd.exe), and then enter the "xxcopy <parms>" command to
check for errors. Maybe XXcopy is crashing. If the console window
suddenly clears, take a look in Event Viewer to see if there are app
errors at the time you ran XXcopy.
Rather than scrolling around inside a console window, might be easier to
use Notepad to view a log. XXcopy is probably writing its output to
stdout, but you could redirect it to a file, like:
xxcopy ... > c:\temp\xxcopy.txt
notepad d:\temp\xxcopy.txt
If you only want to see XXcopy's errors, redirect its stderr to a file
(if XXcopy sends error output to a separate stream):
xxcopy ... 2> c:\temp\xxcopy.txt
notepad c:\temp\xxcopy.txt
File descriptor 1 is stdout, but that's the default, so it can be
omitted. File descriptor 2 is for stderr.
I thought XXcopy had switches to output to log files, like /o (see http://fekete.x10host.com/xxtb3000.htm, or run "xxcopy /?" or "xxcopy /help").
XXcopy had problems. Sometimes it won't copy DLL or EXE files. Error
when copying to a remote (networked) host. Can't use UNCs.
John C. wrote:
When the command line windows does that CLS thing after this command and
parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
The last version of your ancient programme dates from 2016, so probably
is not 100% compatible with Windows 10?
You could just use robocopy instead which comes with any Windows since Windows NT4.
-jw-
MikeS wrote:
John C. wrote:
I have also never had that problem in Windows 8, 10 or 11.
Whenever I run a command in a command prompt window, I can see
what's happening as it does. However, upon completion it the window
resets to basically a clear screen so that I'm unable to see what
was done. Can anybody tell me how to stop it from doing this? I
never had this problem in Windows 7.
TIA
What command(s) are you running?
I still use an ancient freeware command line program called "XXCopy"
to clone folders from one drive or partition to another drive or
partition. Eg. (slightly modified for privacy) a shortcut with this
target:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\Users\(Account name)\My Documents" D:\(Backup folder name) /clone
/YY
When the command line windows does that CLS thing after this command
and parameters run, unlike in Windows 7 I'm unable to see the changes
in file structure that occurred between source and destination.
Joerg Walther wrote:
John C. wrote:
When the command line windows does that CLS thing after this command and >>> parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
The last version of your ancient programme dates from 2016, so probably
is not 100% compatible with Windows 10?
Still does the job like in Windows 7, but the CLS problem after runnning
it is new.
You could just use robocopy instead which comes with any Windows since
Windows NT4.
-jw-
Yeah, it's pretty long in the tooth at this point, I admit. And the
program author has since passed away, leaving the code with an
irritating occasional "you need to check for updates" message that
wastes a lot of time.
I just did a search for "does robocopy do incremental clones?" and found
this page:
https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup
which contains the following: ___________________________________________________________________________
I have been successfully using a variant of the following script for a
few years now:
robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL
Parameters explained
The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
the most important option. It regards your source folder as the
"master", causing robocopy to copy/mirror any changes in the source (new files, deletions etc.) to the target, which is a useful setting for a
backup.
/FFT is a very important option, as it allows a 2-second difference
when comparing timestamps of files, such that minor clock differences
between your computer and your backup device don't matter. This will
ensure that only modified files are copied over, even if file
modification times are not exactly synchronized.
/R:3 specifies the number of retries, if the connection should fail,
and /W:10 specifies a wait time of 10 seconds between retries. These are useful options when doing the backup over a network.
/Z copies files in "restart mode", so partially copied files can be continued after an interruption.
/NP and /NDL suppress some debug output, you can additionally add
/NS, /NC, /NFL to further reduce the amount of output (see the
documentation for details). However, I would suggest to print some debug output during the first runs, to make sure everything is working as
expected.
Additional useful parameters mentioned by other users
/XJD excludes "junction points" for directories, symbolic links that might cause problems like infinite loops during backup. See Brian's
comments for details.
/MT[:N] uses multithreading and can speed up transfers of many small files. For N, a value of 2-4 times the number of cores should do on a
normal machine. Commented by Zoredache on the original question.
Edit in response to Granger's comment:
If you really want to keep files that exist on the destination, but not
on the source side, simply replace the /MIR option with /E. However, I
would strongly suggest to use /MIR when you want to use the destination
for incremental backups. Otherwise any files that have been renamed or
moved at the source will clutter up the destination, meaning you get duplicates. I usually create a subfolder "backup" on the destination
which contains a 1:1 copy of my source folder tree. That way you can
still keep around historical files next to the backup folder and remove
or reorganize them safely later on. ___________________________________________________________________________
I could create test source and destination folders with dummy files and
then run the command to see what happes. I'd have to vet this entire
thing first though, to ensure that I won't lose any files though.
Joerg Walther wrote:
John C. wrote:
When the command line windows does that CLS thing after this command and >>> parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
The last version of your ancient programme dates from 2016, so probably
is not 100% compatible with Windows 10?
Still does the job like in Windows 7, but the CLS problem after runnning
it is new.
You could just use robocopy instead which comes with any Windows since
Windows NT4.
-jw-
Yeah, it's pretty long in the tooth at this point, I admit. And the
program author has since passed away, leaving the code with an
irritating occasional "you need to check for updates" message that
wastes a lot of time.
I just did a search for "does robocopy do incremental clones?" and found
this page:
https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup
which contains the following: ___________________________________________________________________________
I have been successfully using a variant of the following script for a
few years now:
robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL
Parameters explained
The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
the most important option. It regards your source folder as the
"master", causing robocopy to copy/mirror any changes in the source (new files, deletions etc.) to the target, which is a useful setting for a
backup.
/FFT is a very important option, as it allows a 2-second difference
when comparing timestamps of files, such that minor clock differences
between your computer and your backup device don't matter. This will
ensure that only modified files are copied over, even if file
modification times are not exactly synchronized.
/R:3 specifies the number of retries, if the connection should fail,
and /W:10 specifies a wait time of 10 seconds between retries. These are useful options when doing the backup over a network.
/Z copies files in "restart mode", so partially copied files can be continued after an interruption.
/NP and /NDL suppress some debug output, you can additionally add
/NS, /NC, /NFL to further reduce the amount of output (see the
documentation for details). However, I would suggest to print some debug output during the first runs, to make sure everything is working as
expected.
Additional useful parameters mentioned by other users
/XJD excludes "junction points" for directories, symbolic links that might cause problems like infinite loops during backup. See Brian's
comments for details.
/MT[:N] uses multithreading and can speed up transfers of many small files. For N, a value of 2-4 times the number of cores should do on a
normal machine. Commented by Zoredache on the original question.
Edit in response to Granger's comment:
If you really want to keep files that exist on the destination, but not
on the source side, simply replace the /MIR option with /E. However, I
would strongly suggest to use /MIR when you want to use the destination
for incremental backups. Otherwise any files that have been renamed or
moved at the source will clutter up the destination, meaning you get duplicates. I usually create a subfolder "backup" on the destination
which contains a 1:1 copy of my source folder tree. That way you can
still keep around historical files next to the backup folder and remove
or reorganize them safely later on. ___________________________________________________________________________
I could create test source and destination folders with dummy files and
then run the command to see what happes. I'd have to vet this entire
thing first though, to ensure that I won't lose any files though.
"John C." <r9jmg0@yahoo.com> wrote:
Joerg Walther wrote:
John C. wrote:
When the command line windows does that CLS thing after this command and >>>> parameters run, unlike in Windows 7 I'm unable to see the changes in
file structure that occurred between source and destination.
The last version of your ancient programme dates from 2016, so probably
is not 100% compatible with Windows 10?
Still does the job like in Windows 7, but the CLS problem after runnning
it is new.
You could just use robocopy instead which comes with any Windows since
Windows NT4.
-jw-
Yeah, it's pretty long in the tooth at this point, I admit. And the
program author has since passed away, leaving the code with an
irritating occasional "you need to check for updates" message that
wastes a lot of time.
I just did a search for "does robocopy do incremental clones?" and found
this page:
https://superuser.com/questions/814102/robocopy-command-to-do-an-incremental-backup
which contains the following:
___________________________________________________________________________ >>
I have been successfully using a variant of the following script for a
few years now:
robocopy C:\source M:\destination /MIR /FFT /R:3 /W:10 /Z /NP /NDL
Parameters explained
The /MIR option (equivalent to /E /PURGE) stands for "mirror" and is
the most important option. It regards your source folder as the
"master", causing robocopy to copy/mirror any changes in the source (new
files, deletions etc.) to the target, which is a useful setting for a
backup.
/FFT is a very important option, as it allows a 2-second difference
when comparing timestamps of files, such that minor clock differences
between your computer and your backup device don't matter. This will
ensure that only modified files are copied over, even if file
modification times are not exactly synchronized.
/R:3 specifies the number of retries, if the connection should fail,
and /W:10 specifies a wait time of 10 seconds between retries. These are
useful options when doing the backup over a network.
/Z copies files in "restart mode", so partially copied files can be
continued after an interruption.
/NP and /NDL suppress some debug output, you can additionally add
/NS, /NC, /NFL to further reduce the amount of output (see the
documentation for details). However, I would suggest to print some debug
output during the first runs, to make sure everything is working as
expected.
Additional useful parameters mentioned by other users
/XJD excludes "junction points" for directories, symbolic links that
might cause problems like infinite loops during backup. See Brian's
comments for details.
/MT[:N] uses multithreading and can speed up transfers of many small
files. For N, a value of 2-4 times the number of cores should do on a
normal machine. Commented by Zoredache on the original question.
Edit in response to Granger's comment:
If you really want to keep files that exist on the destination, but not
on the source side, simply replace the /MIR option with /E. However, I
would strongly suggest to use /MIR when you want to use the destination
for incremental backups. Otherwise any files that have been renamed or
moved at the source will clutter up the destination, meaning you get
duplicates. I usually create a subfolder "backup" on the destination
which contains a 1:1 copy of my source folder tree. That way you can
still keep around historical files next to the backup folder and remove
or reorganize them safely later on.
___________________________________________________________________________ >>
I could create test source and destination folders with dummy files and
then run the command to see what happes. I'd have to vet this entire
thing first though, to ensure that I won't lose any files though.
Or you could use GUI apps that do mirroring, too, to keep source and destination in sync, like SyncBack Free (*) or FreeFileSync, both free.
(*) Does not support VSS (Volume Shadow Service) to copy locked files.
Have to pay to get a more robust version for that. FreeFileSync
says it supports VSS.
NOTE: robocopy doesn't support VSC, either, nor did XXcopy.
Non-Home users can use vssadmin to create shadows.
I've been using SyncBack Free for a long time. Ever since Bear Bottoms recommended it to me. He also recommended FreeFileSync, which I've
used and will check out again.
I already have so many profiles in SyncBack Free that it'll be kind
of confusing if I add any more. Not sure if it's possible to arrange
them into groups though, but I can't see how to do that.
John C. wrote:
I've been using SyncBack Free for a long time. Ever since Bear Bottoms
recommended it to me. He also recommended FreeFileSync, which I've
used and will check out again.
I already have so many profiles in SyncBack Free that it'll be kind
of confusing if I add any more. Not sure if it's possible to arrange
them into groups though, but I can't see how to do that.
Not intuitive how to create groups (of jobs aka profiles). You create a
new profile, right-click on it to edit it (or select and Shift+M to edit
the profile), and then add other profiles under the one being modified.
While the profiles can be run in parallel, I group them and do NOT elect
to run in parallel. I'm grouping to run the included profiles in order (sequentially) to avoid conflict between them.
For a better description, and since you have it installed, go into its
Help and search on "group". There is a section titled "Creating a
group". You must have at least 2 profiles defined to then group them.
No such thing as a group of one; that would be a solitary profile ran by itself.
I am currently on Syncback Lite 8.0.0. I had Syncback Free, but needed
the VSS support in the Lite edition (which no longer exist, so the SE
edition is the next step up from the Free edition). Syncback is now up
to version 11, but my Lite version is not eligible for update. Nothing
in the SE v11 that I need, so I don't bother with upgrading. I'll
review https://www.2brightsparks.com/syncback/changes.html to see if
anything showed up since v8 that is worth $40 to me for the SE edition.
MikeS wrote:
John C. wrote:
I have also never had that problem in Windows 8, 10 or 11.
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem >>> in Windows 7.
TIA
What command(s) are you running?
Doing "cls" in a Microsoft window, seems to be a built-in
and it also happens to clear the scrollback.
That's not the same as Formfeed, which would not affect the scrollback.
014 12 0C FF '\f' (form feed)
Since "cls" is a built-in, even if you used ProcMon, there would
be no trace of it (no trace of cls.exe loading).
If the OP was using a .bat file, perhaps some clever
individual put a "cls" in there.
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
"E:\1\" /clone /YY /k
where C:\1 and E:\1 are just examples of source and destination folders.
Paul wrote:
MikeS wrote:
John C. wrote:
I have also never had that problem in Windows 8, 10 or 11.
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to >>>> basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem >>>> in Windows 7.
TIA
What command(s) are you running?
Doing "cls" in a Microsoft window, seems to be a built-in
and it also happens to clear the scrollback.
That's not the same as Formfeed, which would not affect the scrollback.
014 12 0C FF '\f' (form feed)
Since "cls" is a built-in, even if you used ProcMon, there would
be no trace of it (no trace of cls.exe loading).
If the OP was using a .bat file, perhaps some clever
individual put a "cls" in there.
No, I'll explain. I'm running XXCopy by Pixelab, Inc. It's a freeware
command line program who's author is now passed away. I have shortcuts
to the program, all for synchronizing different folders with similarly
named folders on other internal hard drives. Here's an example of the
Target line of one such shortcut:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
"E:\1\" /clone /YY /k
where C:\1 and E:\1 are just examples of source and destination folders.
Sorry about the line wrapping. I'm still having fits with Thunderbird
after I went from W7 to W10.
When I run a shortcut like that, I can see the new files in the first
folder scroll by in the command line window. However, once the program
has run, it's as if I ran a CLS command which cleared the window. This
is not what I want, because I want to be able to scroll upwards on the
screen to see what changes were made to the destination folder. In
Windows 7, this was easily possible. In Windows 10 though, that
seemingly automatic CLS command gets run and I lose the information I need.
Hope this helps you understand my dilemma.
"John C." <r9jmg0@yahoo.com> wrote:
Paul wrote:
MikeS wrote:
John C. wrote:
I have also never had that problem in Windows 8, 10 or 11.
Whenever I run a command in a command prompt window, I can see what's >>>>> happening as it does. However, upon completion it the window resets to >>>>> basically a clear screen so that I'm unable to see what was done. Can >>>>> anybody tell me how to stop it from doing this? I never had this problem >>>>> in Windows 7.
TIA
What command(s) are you running?
Doing "cls" in a Microsoft window, seems to be a built-in
and it also happens to clear the scrollback.
That's not the same as Formfeed, which would not affect the scrollback.
014 12 0C FF '\f' (form feed)
Since "cls" is a built-in, even if you used ProcMon, there would
be no trace of it (no trace of cls.exe loading).
If the OP was using a .bat file, perhaps some clever
individual put a "cls" in there.
No, I'll explain. I'm running XXCopy by Pixelab, Inc. It's a freeware
command line program who's author is now passed away. I have shortcuts
to the program, all for synchronizing different folders with similarly
named folders on other internal hard drives. Here's an example of the
Target line of one such shortcut:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
"E:\1\" /clone /YY /k
where C:\1 and E:\1 are just examples of source and destination folders.
Sorry about the line wrapping. I'm still having fits with Thunderbird
after I went from W7 to W10.
When I run a shortcut like that, I can see the new files in the first
folder scroll by in the command line window. However, once the program
has run, it's as if I ran a CLS command which cleared the window. This
is not what I want, because I want to be able to scroll upwards on the
screen to see what changes were made to the destination folder. In
Windows 7, this was easily possible. In Windows 10 though, that
seemingly automatic CLS command gets run and I lose the information I need. >>
Hope this helps you understand my dilemma.
Despite some 'cls' effect after running xxcopy, that doesn't mean you
must lose all of xxcopy's output. It writes to stdout, so just redirect stdout to a file (already mentioned by me, and added upon by Paul):
xxcopy ... > log.txt
^
or |---- very easy to add to the command
V
xxcopy ... >> log.txt
A single greater-than overwrites (without prompt) the file if it
currently exists. A double greater-than appends to the file. If you
don't want the text file in the same folder where you run xxcopy, add a
path to it, like d:\temp\log.txt. Really simple. ANYTHING that xxcopy outputs will go to the text file. Doesn't matter whether the shell's
window got cleared or closed. The stdout got captured in the text file
while xxcopy was running.
Besides the copy operation getting recorded, you could see if xxcopy
issued some error that might've caused the 'cls' effect.
Something goofy is happening with xxcopy, but the workaround is easy.
In fact, since you want to see the output, and using an editor lets you
more easily scroll and even search, you could have Notepad load the log
file, as in:
xxcopy ... > log.txt && notepad log.txt
While xxcopy.exe is an executable program, you don't really need cmd.exe
to load a shell in which to run xxcopy. The "cmd /c" or "cmd /k" isn't needed. However, if any commands are internal to the command
interpreter (cmd.exe), yep, you need to call cmd.exe to run its args.
dir c:\ > log.txt && notepad log.txt && del log.txt
would result in an unknown command error, because there is no dir.exe
program to be found in the current directory nor in the PATH environment variable. So, if using internal commands, use:
cmd /c dir c:\ > log.txt && notepad log.txt && del log.txt
Here I used /c instead of /k, because there is no need to keep the shell window open. The intent is to see the stdout of the program, and by
using Notepad which is a lot easier than trying to scroll around inside
a shell window (and gets truncated if you don't define a big enough
buffer).
A single ampersand runs the next command if errorlevel was zero from the prior command, but a double ampersand runs the next command regardless
of fail/succeed of the prior command. You don't even need to use
cmd.exe to load a shell to run xxcopy. Just run xxcopy, copy its stdout
into a file, and open that file in Notepad. If you don't want the file lingering around after viewing in Notepad, use:
xxcopy ... > log.txt && notepad log.txt && del log.txt
All of those commands (xxcopy, notepad, and del) are in one command
line, so you could specify just one command line in the target field in
a shortcut.
I think you have & and && backwards:
&& executes this command only if previous command's errorlevel is 0 or SUCCESSFUL
Since it is unclear if xxcopy did anything (the OP never mentioned
seeing any output, just that the window cleared of something), the &
would be more appropriate. Whether xxcopy fails or succeeds, the
captured stdout would show if the operation succeeded, or show some
error message, and both are important. However, if there were nothing
in the captured stdout (no copy operation, and no error message) then
I'd try Paul's suggestion of redirecting both stream 1 (stdout) and
stream 2 (stderr) into the same log file.
VanguardLH wrote:
Since it is unclear if xxcopy did anything (the OP never mentioned
seeing any output, just that the window cleared of something), the &
would be more appropriate. Whether xxcopy fails or succeeds, the
captured stdout would show if the operation succeeded, or show some
error message, and both are important. However, if there were nothing
in the captured stdout (no copy operation, and no error message) then
I'd try Paul's suggestion of redirecting both stream 1 (stdout) and
stream 2 (stderr) into the same log file.
When I run XXCopy, I see what it's doing flash by quickly before it
finishes and the CLS effect occurs.
On 4/3/2024 2:52 PM, VanguardLH wrote:
"John C." <r9jmg0@yahoo.com> wrote:Paul
I thought XXcopy had switches to output to log files, like /o (see
http://fekete.x10host.com/xxtb3000.htm, or run "xxcopy /?" or "xxcopy
/help").
XXcopy had problems. Sometimes it won't copy DLL or EXE files.
Error when copying to a remote (networked) host. Can't use UNCs.
John C. wrote:
VanguardLH wrote:
Since it is unclear if xxcopy did anything (the OP never mentioned
seeing any output, just that the window cleared of something), the &
would be more appropriate. Whether xxcopy fails or succeeds, the
captured stdout would show if the operation succeeded, or show some
error message, and both are important. However, if there were nothing
in the captured stdout (no copy operation, and no error message) then
I'd try Paul's suggestion of redirecting both stream 1 (stdout) and
stream 2 (stderr) into the same log file.
When I run XXCopy, I see what it's doing flash by quickly before it
finishes and the CLS effect occurs.
The shell's window may clear, but the captured output won't disappear
from the log file to where you redirected xxcopy's stdout.
VanguardLH wrote:
John C. wrote:
VanguardLH wrote:
Since it is unclear if xxcopy did anything (the OP never mentioned
seeing any output, just that the window cleared of something), the &
would be more appropriate. Whether xxcopy fails or succeeds, the
captured stdout would show if the operation succeeded, or show some
error message, and both are important. However, if there were nothing >>>> in the captured stdout (no copy operation, and no error message) then
I'd try Paul's suggestion of redirecting both stream 1 (stdout) and
stream 2 (stderr) into the same log file.
When I run XXCopy, I see what it's doing flash by quickly before it
finishes and the CLS effect occurs.
The shell's window may clear, but the captured output won't disappear
from the log file to where you redirected xxcopy's stdout.
Well then, I'll enable logging as you recommended. Thanks for the tip.
On 2024-04-10 14:21, John C. wrote:
VanguardLH wrote:
John C. wrote:
VanguardLH wrote:
Since it is unclear if xxcopy did anything (the OP never mentioned
seeing any output, just that the window cleared of something), the & >>>> would be more appropriate. Whether xxcopy fails or succeeds, the
captured stdout would show if the operation succeeded, or show some
error message, and both are important. However, if there were nothing >>>> in the captured stdout (no copy operation, and no error message) then >>>> I'd try Paul's suggestion of redirecting both stream 1 (stdout) and
stream 2 (stderr) into the same log file.
When I run XXCopy, I see what it's doing flash by quickly before it
finishes and the CLS effect occurs.
The shell's window may clear, but the captured output won't disappear
from the log file to where you redirected xxcopy's stdout.
Well then, I'll enable logging as you recommended. Thanks for the tip.
Maybe it is not clearing the screen, but restoring the previous content.
You can check this by writing something to the screen before running the program.
You could also try to run it in a different shell.
Carlos E.R. SAID ...
John C. wrote:
VanguardLH wrote:
The shell's window may clear, but the captured output won't
disappear from the log file to where you redirected xxcopy's
stdout.
Well then, I'll enable logging as you recommended. Thanks for the tip.
Maybe it is not clearing the screen, but restoring the previous
content. You can check this by writing something to the screen
before running the program.
You could also try to run it in a different shell.
What about putting the xxcopy command inside a batch file
(mybatch.bat).
And at the end put
pause
inside.
Reinhard Skarbal <reinhard.skarbal@aon.at> wrote:
Carlos E.R. SAID ...
John C. wrote:
VanguardLH wrote:
The shell's window may clear, but the captured output won't
disappear from the log file to where you redirected xxcopy's
stdout.
Well then, I'll enable logging as you recommended. Thanks for the tip.
Maybe it is not clearing the screen, but restoring the previous
content. You can check this by writing something to the screen
before running the program.
You could also try to run it in a different shell.
What about putting the xxcopy command inside a batch file
(mybatch.bat).
And at the end put
pause
inside.
I mentioned using 'pause' 8 days ago, and Bradshaw mentioned it 6 days
ago. Guess John doesn't want to use a batch script to run xxcopy.
For debugging, I often add:
echo Got here <idnum>
pause
to halt the output to read what is shown, so far, and maybe use other
echo commands to show me values of envvars that have been or should have
been altered. The "got here" breakpoint programming trick is an old
one. I typically add some string to the "Got here", so I know which one
I reached since flow through the code might bounce around to skip other
"Got here" stops.
However, if a defect in xxcopy (under Windows) clears the shell's
window, a following 'pause' won't let you see the prior stdout, but you
will see the "Got here" telling you that xxcopy exited and the script
got to the echo command after the xxcopy command.
Another possibility is xxcopy is outputting a slew of blank lines after
it completes the copy operation(s). Looks like the window got cleared,
but actually the output is before a whole bunch of blank lines, so you
have to scroll back a long ways. No idea what buffer size John set for
the console window. Mine is set to 5000 lines by 132 characters long,
and the window size is 50 x 80. If output exceeds the window size, scrollbars appear to let me scroll back up or out to the right.
In article <eidiekxmr7.ln2@Telcontar.valinor>,
robin_listas@es.invalid says...
On 2024-04-10 14:21, John C. wrote:
VanguardLH wrote:
John C. wrote:
VanguardLH wrote:
Since it is unclear if xxcopy did anything (the OP never mentioned >>>>>> seeing any output, just that the window cleared of something), the & >>>>>> would be more appropriate. Whether xxcopy fails or succeeds, the
captured stdout would show if the operation succeeded, or show some >>>>>> error message, and both are important. However, if there were nothing >>>>>> in the captured stdout (no copy operation, and no error message) then >>>>>> I'd try Paul's suggestion of redirecting both stream 1 (stdout) and >>>>>> stream 2 (stderr) into the same log file.
When I run XXCopy, I see what it's doing flash by quickly before it
finishes and the CLS effect occurs.
The shell's window may clear, but the captured output won't disappear
from the log file to where you redirected xxcopy's stdout.
Well then, I'll enable logging as you recommended. Thanks for the tip.
Maybe it is not clearing the screen, but restoring the previous content.
You can check this by writing something to the screen before running the
program.
You could also try to run it in a different shell.
Hi
What about putting the xxcopy command inside a batch file
(mybatch.bat).
And at the end put
pause
inside.
On 2024-04-10 22:09, VanguardLH wrote:
Reinhard Skarbal <reinhard.skarbal@aon.at> wrote:
Carlos E.R. SAID ...
John C. wrote:
VanguardLH wrote:Maybe it is not clearing the screen, but restoring the previous
The shell's window may clear, but the captured output won't
disappear from the log file to where you redirected xxcopy's
stdout.
Well then, I'll enable logging as you recommended. Thanks for the tip. >>>>
content. You can check this by writing something to the screen
before running the program.
You could also try to run it in a different shell.
What about putting the xxcopy command inside a batch file
(mybatch.bat).
And at the end put
pause
inside.
I mentioned using 'pause' 8 days ago, and Bradshaw mentioned it 6 days
ago.ÿ Guess John doesn't want to use a batch script to run xxcopy.
If the command does a clrscr before exiting, doing a pause in the
calling batch will not help.
But doing a clrscr on exit is a very weird thing to do.
When I wrote programs for MsDOS one of the possibilities was not to use standard text i/o, but set the screen mode (perhaps) and write directly
to screen memory, which was way faster. Setting the screen mode can
include resetting it, and thus erasing the content. Might not happen if
the screen is already set to that same mode externally before calling
the program.
The program might decide not to do any of that if it detects redirection
of the standard output.
For debugging, I often add:
echo Got here <idnum>
pause
to halt the output to read what is shown, so far, and maybe use other
echo commands to show me values of envvars that have been or should have
been altered.ÿ The "got here" breakpoint programming trick is an old
one.ÿ I typically add some string to the "Got here", so I know which one
I reached since flow through the code might bounce around to skip other
"Got here" stops.
However, if a defect in xxcopy (under Windows) clears the shell's
window, a following 'pause' won't let you see the prior stdout, but you
will see the "Got here" telling you that xxcopy exited and the script
got to the echo command after the xxcopy command.
Right.
Another possibility is xxcopy is outputting a slew of blank lines after
it completes the copy operation(s).ÿ Looks like the window got cleared,
but actually the output is before a whole bunch of blank lines, so you
have to scroll back a long ways.ÿ No idea what buffer size John set for
the console window.ÿ Mine is set to 5000 lines by 132 characters long,
and the window size is 50 x 80.ÿ If output exceeds the window size,
scrollbars appear to let me scroll back up or out to the right.
And what's happening (as I believe VanguardLH has pointed out previously
in another post) is that when a batch file or any other way of running a program in a cmd window is run, a cmd window opens and then it opens a
child window to run the program in. When the program finishes running,
the child window is closed and the first cmd window stays open. This is what's been happening to me all along.
"John C." <r9jmg0@yahoo.com> wrote:
And what's happening (as I believe VanguardLH has pointed out previously
in another post) is that when a batch file or any other way of running a
program in a cmd window is run, a cmd window opens and then it opens a
child window to run the program in. When the program finishes running,
the child window is closed and the first cmd window stays open. This is
what's been happening to me all along.
Okay, exactly how are you running the xxcopy.exe program?
- Using Win+R (run dialog)?
- Load a shell (cmd.exe) which opens a console window, and then enter
the xxcopy.exe command?
- Prefixing the xxcopy.exe with cmd.exe (e.g., cmd xxcopy ...)?
- Using a shortcut?
- How?
VanguardLH wrote:
"John C." <r9jmg0@yahoo.com> wrote:
And what's happening (as I believe VanguardLH has pointed out previously >>> in another post) is that when a batch file or any other way of running a >>> program in a cmd window is run, a cmd window opens and then it opens a
child window to run the program in. When the program finishes running,
the child window is closed and the first cmd window stays open. This is
what's been happening to me all along.
Okay, exactly how are you running the xxcopy.exe program?
- Using Win+R (run dialog)?
- Load a shell (cmd.exe) which opens a console window, and then enter
the xxcopy.exe command?
- Prefixing the xxcopy.exe with cmd.exe (e.g., cmd xxcopy ...)?
- Using a shortcut?
- How?
I had backed up my Windows 7 Start Menu which contained all the
shortcuts I'd made for backing up certain folders. An example of Target
line for one of them is:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
"E:\1\" /clone /YY
where the directory names are examples only. The shortcut still does the
job and files are synchronized nicely. I'll briefly see which new files
in the source are being added to the destination, but they only scroll
by quickly and then the child window closes. The original cmd window
remains open.
This isn't how it worked in W7. In W7, there wasn't any child window and after it finished running the command, the window remained open so that
I could scroll upwards and see which changes had been effected.
John C. wrote:
VanguardLH wrote:
John C. wrote:
And what's happening (as I believe VanguardLH has pointed out previously >>>> in another post) is that when a batch file or any other way of running a >>>> program in a cmd window is run, a cmd window opens and then it opens a >>>> child window to run the program in. When the program finishes running, >>>> the child window is closed and the first cmd window stays open. This is >>>> what's been happening to me all along.
Okay, exactly how are you running the xxcopy.exe program?
- Using Win+R (run dialog)?
- Load a shell (cmd.exe) which opens a console window, and then enter
the xxcopy.exe command?
- Prefixing the xxcopy.exe with cmd.exe (e.g., cmd xxcopy ...)?
- Using a shortcut?
- How?
I had backed up my Windows 7 Start Menu which contained all the
shortcuts I'd made for backing up certain folders. An example of Target
line for one of them is:
C:\WINDOWS\system32\cmd.exe /k C:\WINDOWS\system32\xxcopy.exe "C:\1\"
"E:\1\" /clone /YY
where the directory names are examples only. The shortcut still does the
job and files are synchronized nicely. I'll briefly see which new files
in the source are being added to the destination, but they only scroll
by quickly and then the child window closes. The original cmd window
remains open.
This isn't how it worked in W7. In W7, there wasn't any child window and
after it finished running the command, the window remained open so that
I could scroll upwards and see which changes had been effected.
In a shortcut, running an executable still loads a shell, but the
shell's console window will close the moment the program exits. That's
why you needed to prefix the command line with "cmd.exe /k" which should
keep the console window open when the program exits. If the program is opening yet another console window, that will close when the program
exits leaving you back in the first console window.
I've used Windows 7, too, and shortcuts back then always closed the
console window when a program exited that was ran by the shortcut. If
you didn't prefix the executable with "cmd /k", the console window
always closed. Users often note that they ran a program using Win+R,
but can't see anything afterward, because the console window
disappeared.
Seems xxcopy that was abandoned back in 2016 somehow opened its own
shell in which to execute its operations. That the second shell didn't
exit was something xxcopy used to do, but doesn't work under Win10.
Redirecting the output of xxcopy into a logfile means it doesn't matter
what the hell xxcopy is doing with shells. The logfile persists after
the second or first shells exit, so you can still look at the logfile
using Notepad, or your choice of text file viewer/editor.
I don't recall the effect you describe regarding shells getting closed
when using robocopy that has been available since Windows Vista (before
that you had to get the Resource Kit to get robocopy). A long time ago
I looked at using xxcopy, but robocopy did everything, and probably
more. Windows Vista came out in 2007 that included robocopy (but I had
the Resource Kits for earlier Windows versions to get robocopy). XXcopy
got abandoned in 2016. Likely users supplanted xxcopy with robocopy.
There was less and less need or demand for xxcopy, especially since
robocopy came bundled in Windows: no having to get it elsewhere.
I remember going to robocopy because of its minage and maxage arguments
that let me decide how old or new a file was to get included in the copy operation. With xxcopy, I had to write a batch script to parse 'dir' to
get a file's datestamp, and then calculate how old was file (which accomodated leap years, and different days in the spanned months). Was
a lot easire to use minage or maxage in robocopy rather than rely on my
batch script (which needed several debug runs to get correct).
Not sure if this Windows Server site provides any information which is inapplicable to W10, but:
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy
There are other websites that describe how to use Robocopy as well. Like
this one, for instance:
https://lazyadmin.nl/it/robocopy-ultimate-guide/
or this one, which specifically is for W10 users:
https://www.techrepublic.com/article/how-to-quickly-back-up-just-your-data-in-windows-10-with-robocopys-multi-threaded-feature/
Whenever I run a command in a command prompt window, I can see what's happening as it does. However, upon completion it the window resets to basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.
TIA
John C. wrote:
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem
in Windows 7.
TIA
I have found the solution. Instead of right clicking on the shortcuts I
made to use XXCopy to back up my data and then selectiong "Run as Administrator", I:
1. right-click on the shortcut
2. select "Properties"
3. click on the "Advanced" button
4. put a checkmark by "Run as administrator"
5. click the "OK" button
6. click the "OK" button
I'm sure VanguardLH was trying to tell me this, but for some reason I
was misunderstanding him.
Regardless, now when I click on those shortcuts the CMD windows doesn't
open a child window and because I'm using the /k thing, it stays open
and I can see which files were copied.
Over and out on this thread for me. And my thanks to everybody who
replied and tried to help.
Oh yeah, I finally just asked at You.com and the AI told me what to do.
"John C." <r9jmg0@yahoo.com> wrote:
John C. wrote:
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to
basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem >>> in Windows 7.
TIA
I have found the solution. Instead of right clicking on the shortcuts I
made to use XXCopy to back up my data and then selectiong "Run as
Administrator", I:
1. right-click on the shortcut
2. select "Properties"
3. click on the "Advanced" button
4. put a checkmark by "Run as administrator"
5. click the "OK" button
6. click the "OK" button
I'm sure VanguardLH was trying to tell me this, but for some reason I
was misunderstanding him.
Regardless, now when I click on those shortcuts the CMD windows doesn't
open a child window and because I'm using the /k thing, it stays open
and I can see which files were copied.
Over and out on this thread for me. And my thanks to everybody who
replied and tried to help.
Oh yeah, I finally just asked at You.com and the AI told me what to do.
You need the process (xxcopy.exe) to have admin privileges to copy your
own data files?
I didn't realize the source files had read privileges,
or the destination folders had write privileges, that your Windows
account or the Everyone account does not have. Under that scenario, I wouldv'e thought you'd get a prompt to enter the login credentials, or a
UAC prompt to allow the process to run with elevated privs.
These are your data files. The destination folders were probably
created by you. Why do you need admin (elevated) privs on xxcopy to
copy your files to your folders?
VanguardLH wrote:
"John C." <r9jmg0@yahoo.com> wrote:
John C. wrote:
Whenever I run a command in a command prompt window, I can see what's
happening as it does. However, upon completion it the window resets to >>>> basically a clear screen so that I'm unable to see what was done. Can
anybody tell me how to stop it from doing this? I never had this problem >>>> in Windows 7.
TIA
I have found the solution. Instead of right clicking on the shortcuts I
made to use XXCopy to back up my data and then selectiong "Run as
Administrator", I:
1. right-click on the shortcut
2. select "Properties"
3. click on the "Advanced" button
4. put a checkmark by "Run as administrator"
5. click the "OK" button
6. click the "OK" button
I'm sure VanguardLH was trying to tell me this, but for some reason I
was misunderstanding him.
Regardless, now when I click on those shortcuts the CMD windows doesn't
open a child window and because I'm using the /k thing, it stays open
and I can see which files were copied.
Over and out on this thread for me. And my thanks to everybody who
replied and tried to help.
Oh yeah, I finally just asked at You.com and the AI told me what to do.
You need the process (xxcopy.exe) to have admin privileges to copy your
own data files?
No, it still worked but without it and as I've mentioned several times,
the cmd window would open a child window to run XXCopy in and when
XXCopy was finished, the child window would close so that I was unable
to see what had heppened and the original (and blank except for a
command prompt) cmd window would remain open.
I didn't realize the source files had read privileges,
or the destination folders had write privileges, that your Windows
account or the Everyone account does not have. Under that scenario, I
wouldv'e thought you'd get a prompt to enter the login credentials, or a
UAC prompt to allow the process to run with elevated privs.
Until I turned off UAC (which I loath and which sucks), I was getting a prompt.
These are your data files. The destination folders were probably
created by you. Why do you need admin (elevated) privs on xxcopy to
copy your files to your folders?
I couldn't tell you. You'd have to ask Microsoft.
"John C." <r9jmg0@yahoo.com> wrote:
VanguardLH wrote:
"John C." <r9jmg0@yahoo.com> wrote:
John C. wrote:You need the process (xxcopy.exe) to have admin privileges to copy your
Whenever I run a command in a command prompt window, I can see what's >>>>> happening as it does. However, upon completion it the window resets to >>>>> basically a clear screen so that I'm unable to see what was done. Can >>>>> anybody tell me how to stop it from doing this? I never had this problem >>>>> in Windows 7.
TIA
I have found the solution. Instead of right clicking on the shortcuts I >>>> made to use XXCopy to back up my data and then selectiong "Run as
Administrator", I:
1. right-click on the shortcut
2. select "Properties"
3. click on the "Advanced" button
4. put a checkmark by "Run as administrator"
5. click the "OK" button
6. click the "OK" button
I'm sure VanguardLH was trying to tell me this, but for some reason I
was misunderstanding him.
Regardless, now when I click on those shortcuts the CMD windows doesn't >>>> open a child window and because I'm using the /k thing, it stays open
and I can see which files were copied.
Over and out on this thread for me. And my thanks to everybody who
replied and tried to help.
Oh yeah, I finally just asked at You.com and the AI told me what to do. >>>
own data files?
No, it still worked but without it and as I've mentioned several times,
the cmd window would open a child window to run XXCopy in and when
XXCopy was finished, the child window would close so that I was unable
to see what had heppened and the original (and blank except for a
command prompt) cmd window would remain open.
I didn't realize the source files had read privileges,
or the destination folders had write privileges, that your Windows
account or the Everyone account does not have. Under that scenario, I
wouldv'e thought you'd get a prompt to enter the login credentials, or a >>> UAC prompt to allow the process to run with elevated privs.
Until I turned off UAC (which I loath and which sucks), I was getting a
prompt.
These are your data files. The destination folders were probably
created by you. Why do you need admin (elevated) privs on xxcopy to
copy your files to your folders?
I couldn't tell you. You'd have to ask Microsoft.
No, I asked *you*. You're the only one that knows why your source or destination requires admin privileges. No other program would need
admin privs to do the task you want xxcopy to do, so it looks like
xxcopy is screwed up.
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 7 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 151:23:24 |
| Calls: | 46 |
| Files: | 21,492 |
| Messages: | 65,413 |