Pádraig Brady wrote:
On 11/07/2011 10:27 PM, Linda Walsh wrote:
I'd like to request an RFE for the groups command to add 2 switches:
-1 - print groups in 1 column (cf. ls -1)
-0 - print groups followed by null (cf. find et al)
reasons: have groups with spaces in them
Pádraig Brady wrote:
Hmm. I suppose by extension that `id -Gn` should accept -1 too.
But do you really want to support group names with spaces?
`groupadd` for example won't allow this.
I suppose integration with LDAP etc. might get arbitrary group names.
... i.e. some don't have names
Paul Eggert wrote:
A) catch INT ( catchable signals), and remove any files that are
'incomplete'
That might cause trouble in other cases. For example, cp A B where
B already exists.
===
Am **only** suggesting this where 'B' has already been opened
and truncated by stuff being
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that
users of
the core utilis are ot allowed to find bugs...convenient.
Paul Eggert wrote:
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial copy than no copy at all. As an extreme example,
if I'm doing 'cp /dev/tty A', I do not want
[Thought I send out rspns to this, but can't find it in my outgo,
so...recomposing/sending,
sorry for delay)
On 11/15/11 12:46, Linda A. Walsh wrote:
Better than leaving *doo doo* in a file
Sometimes, but not always. I can think of plausible cases where I'd
rather have a partial
Jim Meyering wrote:
Linda A. Walsh wrote:
Hmmm Dang strange processes on bugs... can't submit directly bug
can just by
emailing it to the email list? ... (bureaucracy!)
Linda Walsh wrote:
This should be filed under bugs, not under support, but it seems that users of
the core utilis
Pádraig Brady wrote:
On 06/03/2012 11:13 PM, Linda Walsh wrote:
Within in the past few years, use of ranges in RE's has become
unreliable due to some locale changes sorting their native character
sets such that aAbByYzZ (vs. 'C' ordering ABYZabyz).
There seems to be a problem in when a user
Pádraig Brady wrote:
On 06/04/2012 06:03 AM, Linda A. Walsh wrote:
Pádraig Brady wrote:
On 06/03/2012 11:13 PM, Linda Walsh wrote:
Within in the past few years, use of ranges in RE's has become
unreliable due to some locale changes sorting their native character
sets
Jim Meyering wrote:
These commands would evoke an invalid diagnostic:
$ mkdir d ln -s d s env rm -r s/
rm: cannot remove 's': Too many levels of symbolic links
remove.c was stripping trailing slashes from s/ before passing
the name to rm. But a trailing slash may change the semantics,
Paul Eggert wrote:
On 09/04/2012 10:46 AM, Linda A. Walsh wrote:
I would assert that the trailing . shouldn't be stripped either.
If we were designing anew, I'd be inclined to agree with you.
But there are probably people expecting the standard behavior now,
i.e. expecting
Paul Eggert wrote:
On 09/04/2012 04:21 PM, Linda A. Walsh wrote: Paul Eggert wrote:
expecting it to do nothing useful other than issue an error?
Sure. People might expect the utility to complain about
what they consider to be obvious typos, rather than to
remove files they don't
Paul Eggert wrote:
On 09/04/2012 11:58 PM, Linda A. Walsh wrote:
I'm not talking for interactive use... I'm talking for use in a script
that might run on systems that are not mine -- so I can't rely on shell
settings.
Yes you can. Just start the script with #!/bin/sh, as usual
Pádraig Brady wrote:
On 06/01/2013 02:02 AM, Linda Walsh wrote:
in Coreutils 8.21.1.1 (x86_64) on snoozy
When I type in ls -k, I get a small listing (filenames only horizontally)
(and no sizes).
When I type in ls -lk, I get a long listing -- but it isn't using K, but
bytes.
Since
Bob Proulx wrote:
Gian Ntzik wrote:
It seems that using rm -r with a path that goes into a (non-empty)
directory intended for removal (and back up e.g. using dot-dots) fails
to remove the directory. The directory is rendered empty, but itself not
removed.
For example,
$ mkdir -p /tmp/a/b/c
$
f0r...@free.fr wrote:
I can confirm. Tests show that the parent folder ACL Default mask is not inherited as the ACL Access mask of the file|dir created by cp|mv.
What file system and core utils are you using?
Are you using a file system that has alternate user-data forks
or extended
16 matches
Mail list logo
