Hi.
When doing something like:
cp --no-dereference --preserve=all --parents --no-clobber "${pathname}"
"${destination}"
Then the file (if it's not a directory) will be copied to
${destination}/${pathname} including all the directories within ${pathname}
(e.g. ./foo/bar/file).
While the owner (use
On Tue, 2011-05-31 at 09:42 +0200, Ondrej Vasik wrote:
> Could you please specify coreutils version where you experience the
> issue?
Sorry, forgot that.
This was the corutils from Debian sid, which is currently 8.5.
> but in the case of extended attributes and
> SELinux context possible failure
ungsprogramme
Ⅱ.5¼-inch-DS-DD-floppy-disk-image.kern.log
escape_char /
comment_char %
LC_IDENTIFICATION
title "scientia.net default locale"
source "scientia.net"
contact "Christoph Anton Mitterer"
email
Oh one further solution:
- document more properly in the manpage and --help, what -u really is,
and especially that it may not behave as expected, with other
locales/collations.
Perhaps even giving an example, so that people understand the
seriousness of that.
- add companion option, maybe -U, wh
Hey Pádraig
On Sat, 2015-11-14 at 11:06 +, Pádraig Brady wrote:
> Unfortunately the roman numeral code points compare equal:
>
> $ printf '%s\n' Ⅱ Ⅰ | ltrace -e strcoll sort
> sort->strcoll("\342\205\241", "\342\205\240") = 0
> Ⅱ
> Ⅰ
>
> If you compare at the byte level you'll get ap
Hey.
Man page of logname say:
"Print the name of the current user."
IMO that's ambiguous as it's probably ought to be the name returned by
getlogin().
So when I login as normal user, and "su -" to root, logname won't print
"root" but the normal user.
However, what most people will understand und
Hey.
The timeout(1) manpage says:
-k, --kill-after=DURATION
also send a KILL signal if COMMAND is still running
this long after the initial signal was sent
My naive assumption would have been that --kill-after=0 means that a
signal is sent immediately after the
On Mon, 2021-10-11 at 16:49 +0100, Pádraig Brady wrote:
> Well that wouldn't be that useful functionality,
> as why not just send a single kill signal in that case.
Well with the same argumentation one could say that timeout 0 command
doesn’t execute the command at all, since why should one call i
Hey.
This time I've also checked the 9.0 documentation (hopefully I wasn't
just too blind).
I noticed that whenever --foreround is used, timeout exits with a 124
status (instead of the documented 128+9) regardless of whether the KILL
is sent because of --signal=KILL or --kill-after=n .
Thanks
On Mon, 2021-10-11 at 22:04 +0100, Pádraig Brady wrote:
> +However if the @option{--foreground} option is specified then
> +@command{timeout} will not send any signals to its own process,
> +and so it will exit with one of the other exit status values
> detailed above.
So 137 is only used when the
On Mon, 2021-10-11 at 22:20 +0100, Pádraig Brady wrote:
> For that use case it's probably best to use --preserve-status,
> in which case the 137 from the child getting the SIGKILL
> will be propagated through.
But wouldn't that make me loose the 124, if COMMAND could actually be
SIGTERMed?
Hey.
One more thing on this, since I've just read through:
https://www.gnu.org/software/coreutils/manual/html_node/timeout-invocation.html#timeout-invocation
That does IMO *not* document the behaviour:
--kill-after=duration says:
>This option has no effect if timeout’s duration is 0 which disabl
Thinking again about this:
Don't you think one looses quite something if, with --foreground, one
cannot differ (via the exit status) between a timeout that allowed the
program to clean up and one (when KILLing) that didn't?
Even if the KILL happens via killing timeout itself, couldn't it just
re
On Tue, 2021-10-12 at 14:50 +0100, Pádraig Brady wrote:
> That is a fair point.
Thanks for reconsidering :-)
> If one is using --kill-after you have to
> check for both 124 and 137 anyway to see if it timed out.
> It is useful to know whether the command was forcably killed.
> Using --foreground
On Tue, 2021-10-12 at 14:53 +0100, Pádraig Brady wrote:
> Well DURATIONs of 0 were mentioned a little below that.
Hmm ok,... I see, since both use the symbol ... and you use
the word "associated"... one could have also understood it from the
beginning like that.
> -This option has no effect if @
On Fri, 2022-03-18 at 14:59 +, Pádraig Brady wrote:
> The attached should fix this up.
Thanks!
Hey.
Is this still being considered?
Thanks,
Chris.
Hey.
Since on UNIX/Linux it is effectively always binary mode, shouldn't the
(sha|md5)*sum tools default to that, and especially also generate
output with the "*" flag set?
Cheers,
Chris.
Hey.
When I want to count the nominal sizes of the (usually regular) files
in a directory I do something like:
du --apparent-size --block-size=1
This however also counts in the sizes of the directories themselves
(and I guess also of symlinks, etc.).
The "problem" with that is in particular, t
On Thu, 2023-03-02 at 16:01 +, Pádraig Brady wrote:
> There are many possible filtering options,
> which are probably best left to `find` (as per your example).
> This was also mentioned previously at:
> https://lists.gnu.org/archive/html/coreutils/2013-04/msg00043.html
Sure, but the problem
Hey Glenn
On Thu, 2023-03-02 at 10:20 -0700, Glenn Golden wrote:
> Would something like this work for you?
>
>
> $ echo dir1_file1 > dir1/file1
> $ echo dir1_file2 > dir1/file2
> $ echo dir2_file1 > dir2/file1
>
Oh, and I forgot to mention another main drawback of such a script.
It cannot (easily) be used with du's other options, cause that would
require some options parser to be added to the script.
While this is of course rather easily possible (getopt) the main
problem there is IMO to keep it up2date
On Sat, 2023-03-04 at 14:58 -0800, Paul Eggert wrote:
> What's the motivation here? Does this have something to do with
> reproducible builds?
No, nothing with reproducibility - at least not from my side. It's
really just to get a number for the "actual" data. And yes it's clear
that one can argu
Hey Paul.
On Sat, 2023-03-04 at 17:00 -0800, Paul Eggert wrote:
>
> So I installed the attached patch
AFAICS this is now only documented in the info page?
Would you mind to add a shorter notice to the manpage as well?
Thanks,
Chris.
In principle I have no strong opinion on what the behaviour should be.
But if one strictly follows the POSIX wording:
>The following exit values shall be returned:
> 0
>All input files were [copied/moved] successfully.
>>0
>An error occurred.
The change seems to make
Hey.
At least as of 9.1 (on Debian), it seems that cksum cannot --check a
sums file in the untagged style:
$ touch a b
$ cksum -a sha512 --tag * > sums.tagged
$ cksum -a sha512 --untagged * > sums.untagged
$ cat sums.tagged
SHA512 (a) =
cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d
btw: I haven't check now, but I'd guess all this applies to md5sum and
friends, too.
Hey.
It seems to me that the output of --check mode in cksum (and likely
also in md5sum and friends) suffers from improper escaping (which,
IIRC, is not even documented for that output... but may be wrong):
$ touch a $'new\nline' '\n' z
$ ls -al
total 0
drwxr-xr-x 1 calestyo calestyo 24 Jul 1 0
On Sat, 2023-07-01 at 09:05 +0200, Andreas Schwab wrote:
> $ cksum -a sha512 -c sums.untagged
Haha... I'm so dumb. ^^
Thanks for pointing to the obvious.
Thus closing.
Cheers,
Chris.
On Sat, 2023-07-01 at 17:07 +0100, Pádraig Brady wrote:
> Right. We traditionally didn't escape any chars in the --check
> output,
> but that changed with
> https://github.com/coreutils/coreutils/commit/646902b30
> To minimize escaping, that patch only considered the '\n' character,
> but we should
Oh and I've seen you really escape \ only if it's the first character.
Same here, I'd suggest to apply the same escaping rules as for the
other output, and escape '\\' '\n' and '\r' as soon as any of them
occurs in the output.
On Sat, 2023-07-01 at 18:53 +0100, Pádraig Brady wrote:
> That's not a common case I suppose,
> so I'm amenable to using the consistent escaping here.
Good :-)
> Info docs already contain:
>
> "Without ‘--zero’, if FILE contains a backslash, newline, or carriage
> return, the line is started wi
On Tue, 2023-07-11 at 12:27 +0100, Pádraig Brady wrote:
> Full escaping and doc adjustments pushed at:
> https://git.sv.gnu.org/cgit/coreutils.git/commit/?id=86614ba1c
Thanks :-)
Cheers,
Chris.
33 matches
Mail list logo
