Re: wish: cp: output some sort of message if copying was interrupted
Philip Rowlands schrieb: On Sun, 24 May 2009, Elmar Stellnberger wrote: If I issue a 'cp -a' on one konsole and a 'killall -s SIGINT cp' on another konsole cp -a will terminate just as if it had finished copying. Not quite; the exit status passed to the calling process will show the signal used to terminate cp. This can in turn be used to diagnose a display any desired message, for example in bash: $ PROMPT_COMMAND='[ $? -ne 0 ] echo Command exited abnormally' $ true $ false Command exited abnormally Alternatively it would be possible to construct a signal-aware wrapper around cp and other interactive processes. My regard would be to let it print something like 'copying interrupted' (... and may be continued by issuing the same command once more). As the tools already exist to build this feature it's not a good fit for adding to cp. The specific message regarding resumed copies would be highly dependent on the arguments to cp. Cheers, Phil Yes that will be a good solution for the usage of cp within shell scripts. However in most cases I invoke cp directly via the command line so that it is somehow awkward and very easy to forget having to issue always an extra command that tests for the return value (i.e. cp echo xx). What about nonetheless issuing a message on stderr as long as no -q/--quiet option is given for the cases where the return value becomes nonzero? It is not possible to create a shell alias for this since testing for the return value must take place right -after- executing cp. A wrapper shell script however would make things even worse since shell scripts will as well be invoked fromout of other shell scripts instead of being applied for user issued commands only. Other coreutils as rm are even more verbose than that, so why just solely not cp? Making a difference just on cp will be somehow conterintuitive. rm hug rm: remove write-protected regular empty file `hug'? y rm: cannot remove `hug': Permission denied P.S.: In what kind of situation will it not be adequate to resume copying by issuing the same cp-command again? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: wish: cp: output some sort of message if copying was interrupted
Philip Rowlands schrieb:
On Fri, 5 Jun 2009, Elmar Stellnberger wrote:
Yes that will be a good solution for the usage of cp within shell
scripts. However in most cases I invoke cp directly via the command line
so that it is somehow awkward and very easy to forget having to issue
always an extra command that tests for the return value (i.e. cp echo
xx).
The scenario under discussion was a simultaneous (long-running) cp and
killall -s SIGINT cp. Shouldn't the user expect the POSIX-defined
default behaviour for the signal?
It is not possible to create a shell alias for this since testing for
the return value must take place right -after- executing cp.
Shell functions allow arguments and multiple commands.
What about nonetheless issuing a message on stderr as long as no
-q/--quiet option is given for the cases where the return value becomes
nonzero?
Other coreutils as rm are even more verbose than that, so why just
solely not cp? Making a difference just on cp will be somehow
conterintuitive.
rm hug
rm: remove write-protected regular empty file `hug'? y
rm: cannot remove `hug': Permission denied
cp does print diagnostic messages to stderr in many cases where the
return value is nonzero, e.g. permission errors. It is not an error to
terminate immediately on SIGINT however, so I'm unsure it's worthwhile
adding such output to cp given that wrapper scripts and shell functions
can provide the same feature if so desired.
P.S.: In what kind of situation will it not be adequate to resume
copying by issuing the same cp-command again?
cp is not always idempotent, e.g. when using --backup. It's also
inefficient to overwrite destination files which already exist; rsync
would be better for repeat copies.
Cheers,
Phil
Providing a wrapper that checks the return value is not too difficult:
cp() { command cp $@ || echo error $? copying files.; }
However outputting an interrupted by keyboard message on SIGINT seems to
be more tricky since installing a signal handler beforehand invoking cp
will not do this job:
cp() { local sigh=$(trap -p SIGINT); trap echo copying interrupted by
SIGINT/Ctrl-C. 2 SIGINT
command cp $@ || echo error copying files.;
trap $sigh SIGINT; }
-- same results as with pure cp() from above as any new process will
install its own signal handlers
If the goal(-dir) did not exist beforehand invocation of copy specifying
the --update switch to cp should suffice for a continuation of copying.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
wish: cp: output some sort of message if copying was interrupted
If I issue a 'cp -a' on one konsole and a 'killall -s SIGINT cp' on another konsole cp -a will terminate just as if it had finished copying. My regard would be to let it print something like 'copying interrupted' (... and may be continued by issuing the same command once more). The problem I have run into is that I have a half copied directory but can not remember having interrupted cp -a. Unfortunately ~/.bash_history does not contain a long enough history back in time to see if there had really been such a killall potentially issued by a hacker. Regards, Elmar ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: grep -R hangs when issued upon certain directory
Bob Proulx schrieb:
Elmar Stellnberger wrote:
I am not sure what grep does not like about my home directory, but as
soon as I issue a grep -R Testtext * in my home dir grep will start to
hang not triggering any further disk access after a short while.
Bugs in grep should be reported to bug-grep. But you have contacted
the bug-coreutils list instead. We don't know much about grep here.
The bug reporting address for most programs is documented in the
manual and in the output from --help.
Tried to get a backtrace by installing coreutils-debuginfo and
coreutils-debugsource but gdb does not find any symbols:
rpm -ql coreutils-debugsource coreutils-debuginfo|grep grep
(nothing found)
I am not familiar with those packages. I assume that they are
specific to a particular distribution. Meanwhile this is the mailing
list for the development of the coreutils for the GNU project. Those
packages are not part of the GNU Project.
But I don't think they are related to grep. This was confirmed by
your not finding any files relating to grep in them. They are
unrelated to your issue with grep.
i.e. it does not seem to descend to subdirs)
Even though this isn't the right place to comment I can't help but to
suggest something. The most likely problem is that you have a pipe
file in your home directory. When grep reads the file it is blocked
waiting for input. Since nothing is writing the file this input never
arrives and grep waits for it. You would need to --exclude that file.
The grep -R option is really just a hack. Adding it requires adding
much of 'find's functionality such as --exclude and others. It
violates the principles of the Unix philosophy. Instead it is better
to use 'find' for finding files to act upon with a command. Here is a
better way to search all files in your home directory.
find . -type f -exec grep Testtext {} +
Bob
thx, that has resolved my issue.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
cp -a refuses to devolve file mode
cp -a refuses to devolve the file mode when I copy a certain file between two ext3 volumes whereas it does not report any error: cat syncit cp -a /home/./downloads/system/freebsd/bootstrap/etch/debootstrap /mnt/home-mirror/home/./downloads/system/freebsd/bootstrap/etch/debootstrap echo $? for i in /home /mnt/home-mirror/home; do ls -l $i/./downloads/system/freebsd/bootstrap/etch/debootstrap; done ./syncit 0 lrwxr-xr-x 1 root users 34 Jan 21 04:56 /home/./downloads/system/freebsd/bootstrap/etch/debootstrap - /compat/linux/usr/sbin/debootstrap lrwxrwxrwx 1 root users 34 Feb 3 17:06 /mnt/home-mirror/home/./downloads/system/freebsd/bootstrap/etch/debootstrap - /compat/linux/usr/sbin/debootstrap The file mode should be the same since cp has just successfully copied that file. I could not reproduce this behaviour in an artificial test setting. Please answer me as soon as possible to issue further tests since I do not know for how long this anomaly will hold. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
mv executed incompletely due to insufficient privileges
mv /opt/kde3/share/services/basket_config_features.desktop ~/unbenutzt/ mv: Entfernen von „/opt/kde3/share/services/basket_config_features.desktop“ nicht möglich: Keine Berechtigung (E.: removing 'opt/kde3/share/services/basket_config_features.desktop' not possible: insufficient privileges) package/version: coreutils-5.93-20 In this case the privileges suffice for creating a new directory entry for the destination file but not for removing the source file. Awkwardly the result will depend on whether the target location resides on the same mount point or not: * same mount point: nothing is done * different mount point: file is copied but not deleted Generally we expect mv to be atomic by default. If the --backup switch is stated we may want it to behave like a copy and delete in sequence (copied though not deleted). Notwithstanding the result should always be the same no matter whether source and destination reside on different mount points! Elmar Stellnberger ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
ls gets confused by IFS environment variable
LS gets confused as soon as the IFS environment variable only contains control characters. # IFS contains an NL only: bash IFS=$(echo -e \n) ls /bin/ls: Ungültige Option -- „/bin/ls --help“ gibt weitere Informationen. # IFS contains TAB,NL and SPACE: IFS=$(echo -e \t\n) ls -1 bin boot dev ... Strange! There is also nothing about IFS in the man or info pages of ls. Why has IFS an influence on ls at all? ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
[Fwd: ls gets confused by IFS environment variable]
coreutils-5.93-20 ---BeginMessage--- LS gets confused as soon as the IFS environment variable only contains control characters. # IFS contains an NL only: bash IFS=$(echo -e \n) ls /bin/ls: Ungültige Option -- „/bin/ls --help“ gibt weitere Informationen. # IFS contains TAB,NL and SPACE: IFS=$(echo -e \t\n) ls -1 bin boot dev ... Strange! There is also nothing about IFS in the man or info pages of ls. Why has IFS an influence on ls at all? ---End Message--- ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
