Andrey Sheyko wrote:
Hello!
I've found out that wc -l doen't count the last line if there is no CR in the
end of line
It's the 'CR' (or NL) at the end of the line that makes it a "new line"...
without that, you just have text appended to the end of the file...
積丹尼 Dan Jacobson wrote:
One finds that -d completely nullifies any -R flag of ls,
so maybe print a warning etc. Or warn on the man page, etc.
What would you want it to do? "-d" says to show info on the directory
and NOT expand it.
"-d" says give info on the "name" that you type in rather
reopen 10468
thanks
=
Not to stir up problems, but those who do not learn from history are
doomed to repeat it. Nothing in this re-opening should be
taken personally, but am trying to follow-up on a bug that, I
felt, was improperly closed, and that now looks like it may be
'touched'
This is a fix/work-around for (RFE#19849 (bug#19849) which was
about addingg options to expand tabs and/or set a tabsize
for output from 'du' so output would line up as intended.
Without that enhancement, the current output is "messed
up" on terminals/consoles that don't use hard-coded-const
(skip to end if you don't care to read how I found this
mess)...
Paul Eggert wrote:
Linda Walsh wrote:
I had one file that it bailed on
saying it has an invalid UTF-8 encoding -- but the line was
recursive starting from '.' -- and it didn't name the file
That's pretty vague. Can you reprodu
I think you'll find this was reported 3 years ago..
"bug#10471: Severe or critical - deletes existing files and leaves
nothing. (cp)"
https://lists.gnu.org/archive/html/bug-coreutils/2015-04/msg1.html
Unfortunately it was closed it out w/the reason that it was a
"cygwin/windows-only"
積丹尼 Dan Jacobson wrote:
(info "(coreutils) who invocation") says
If given no non-option arguments, ‘who’ prints the following
information for each user currently logged on: login name, terminal
line, login time, and remote hostname or X display.
$ who
The same thing happens on openSuSE -- I
Erik Auerswald wrote:
Linda A. Walsh noticed a similar thing:
The same thing happens on openSuSE
Looked into this a bit more and found that while
'w' and 'who' didn't work, "last" did.
Tracked it down to this...
from the linux programmer's manual UTMP(5)
it says conforming
L. A. Walsh wrote:
Erik Auerswald wrote:
Linda A. Walsh noticed a similar thing:
The same thing happens on openSuSE
Looked into this a bit more and found that while
'w' and 'who' didn't work, "last" did.
Tracked it down to this...
from the li
coreutils-8.23 x64
manpage says:
If FILE is not specified, use /var/run/utmp. /var/log/wtmp as
FILE is
common. If ARG1 ARG2 given, -m presumed: 'am i' or 'mom
likes' are
usual.
Behavior says:
access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or
dire
It doesn't seem rmdir and mkdir are behaving "reciprocally"...
If I type
mkdir -p ./a/b/c # no error
rmdir -p ./a/b/c # get error msg, but a,b,c removed.
1) thinking either rmdir shouldn't generate an error or mkdir should
mkdir -p a/../b # no error
rmdir -p a/../b # error, but
L. A. Walsh wrote:
coreutils-8.23 x64
who manpage says:
If FILE is not specified, use /var/run/utmp. /var/log/wtmp as FILE is
common. If ARG1 ARG2 given, -m presumed: 'am i' or 'mom likes' are
usual.
Behavior is:
access("/var/run/utmpx", F_OK)
Michael Schwager wrote:
I
don't have single quotes in many of my filenames, although I do in some.
---
How did this get displayed? In shell,
'foo \' bar' wouldn't be displayed correctly since you can't
use backslash to escape inside a single quoted string.
That is just plain ugly.
--
Eric Blake wrote:
touch 'a b' c
That's your problem. Paul did:
$ touch 'a b' c
He didn't list his creation command. How
would you know?
with two spaces, not one.
---
You are assuming that. But if he didn't list how
he created them...
Where (or under what conditions
Eric Blake wrote:
If the idea is that the quoting is there to make copy-and-pasting into a
shell command line easier, then there is nothing we can do that is less
aggressive, since failing to quote spaces changes what the shell will
do.
I assume you are talking about "quoting-style=she
Eric Blake wrote:
Knowing the pitfalls makes it easier to justify why an output that is
unambiguous was chosen as the new default over the previous ambiguous
output; any further changes to the default are now a matter of
fine-tuning about how much (or how little) decoration we can get away
with
Eric Blake wrote:
He didn't have to. His point was merely that with the old ls, you can
have inherently ambiguous situations. Think of it as an exercise for
the reader to figure out ways to get into those ambiguous situations.
Good communication isn't supposed to be
a puzzle. Cr
Eric Blake wrote:
On 11/11/2016 03:25 PM, L. A. Walsh wrote:
Eric Blake wrote:
If the idea is that the quoting is there to make copy-and-pasting into a
shell command line easier, then there is nothing we can do that is less
aggressive, since failing to quote spaces changes what the shell
In the 8.26 NEWS file, I found this paragraph:
These programs are intended to conform to POSIX (with BSD and other
extensions), like the rest of the GNU system. By default they conform
to older POSIX (1003.2-1992), and therefore support obsolete usages
like "head -10" and "chown owner.group
L. A. Walsh wrote:
In the 8.26 NEWS file, I found this paragraph:
These programs are intended to conform to POSIX (with BSD and other
extensions), like the rest of the GNU system. By default they conform
to older POSIX (1003.2-1992), and therefore support obsolete usages
like "hea
The new ls doesn't maintain backwards compatibility.
The default options now add extraneous quotes to
some filenames.
Anyplace one uses 'ls -1' to read 1 file/line
now breaks.
This is a regression as it breaks existing
scripts and behavior.
Andreas Schwab wrote:
On Jan 06 2017, L A Walsh wrote:
The new ls doesn't maintain backwards compatibility.
The default options now add extraneous quotes to
some filenames.
---
Does it?
$ touch 'a b'
$ ls -1 | grep "'"
Sorry, you are right.
Paul Eggert wrote:
L A Walsh wrote:
Having 'ls' show different output through a pager
than it does when scrolling off the screen is not a standard
feature
Sure it is. 'ls' has done that since then 1980s. 'ls' shows multicolumn
output when the output is a
Paul Eggert wrote:
L A Walsh wrote:
Having 'ls' show different output through a pager than it
does when scrolling off the screen is not a standard feature.
Sure it is. 'ls' has done that since then 1980s. 'ls' shows multicolumn
output when the output is a
Paul Eggert wrote:
On 01/09/2017 10:48 AM, L A Walsh wrote:
That's not what I'm used to:
I couldn't parse your email.
---
1) I ran the ls command on a directory, shows 4 columns
(that were in color).
Ishtar:/tmp/tmp> ls
12345678 a.exe*
Eric Blake wrote:
But that's EXACTLY what POSIX has specified, because it has been
existing practice for YEARS.
---
A bit louder Eric, you can't be heard.
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html
"STDOUT
The default format shall be to list one entry per
Eric Blake wrote:
On 01/09/2017 12:48 PM, L A Walsh wrote:
Sure it is. 'ls' has done that since then 1980s. 'ls' shows
multicolumn output when the output is a tty, and single-column output
when piped into a pager.
That's not what I'm used to:
ls alia
Eric Blake wrote:
Good or not, it IS what happens, and we can't change it due to years of
usage.
You are coming into the middle of the discussion.
I wasn't asking for a change to _that_ specific behavior.
I'm against adding more/new behaviors that also change
outpu
Paul Eggert wrote:
On 01/09/2017 12:00 PM, L A Walsh wrote:
I wasn't asking for a change to _that_ specific behavior.
You argued that it's not standard for 'ls' to behave differently when
piping output to a pager, and that the recent change was therefore
undesirable.
How do you reopen a bug that was closed before I even replied?
Pádraig Brady wrote:
tag 25388 notabug
close 25388
stop
On 09/01/17 18:48, L A Walsh wrote:
ls alias on my machines:
alias ls='ls -CF --show-control-chars --color=always'
Note a caveat of the above is that it c
reopen 25388
thanks
It's still a bug as it goes against adding new behaviors that
generate different output based on destination = tty or not.
Pádraig Brady wrote:
tag 25388 notabug
close 25388
stop
On 09/01/17 18:48, L A Walsh wrote:
ls alias on my machines:
alias ls='ls
Eric Blake wrote:
On 01/09/2017 02:35 PM, L A Walsh wrote:
I also stand for it being strongly against GNU
standards to add more such behaviors.
'ls' did not recently add any more cases where tty output differs from
non-tty output when all other things are equal in the default
Eric Blake wrote:
On 01/09/2017 01:53 PM, L A Walsh wrote:
And POSIX merely codified existing practice (this is nothing new - it
has been this way since the 70's)
---
Not anymore.
Breaking "rm -fr ." wasn't an existing practice except
at BSD-using dists (like
Eric Blake wrote:
You're quoting me out of context.
Your context was not clear.
When coupled with the sentences
Your "But" started that sentence responding to my statement.
While you may have thought you included all previous context,
it was interwoven with my statements, so the co
I was trying to compile a file in the 'src' dir of the coreutils,
called 'retab.c' but I got all sorts of weird errors. Trying
to do a make clean and remaking it I now get it in a bunch of files:
./lib/time.h:20:1: error: stray '@' in program
@ PRAGMA_SYSTEM_HEADER @
^
./lib/time.h:20:24: error:
Eric Blake wrote:
But it
sounds like since you bypassed a step and messed up your tree, it may be
easiest to just rerun ./bootstrap to fix the incomplete job (bootstrap
runs automake under the hood as needed).
By the way, this isn't a bug in coreutils, so much as a build question,
so it might
In programs that take tabstops, as an alternative to a tabsize, I've always
seen tabs beyond the end of the list taken as equal to the highest tab-stop
difference. So for a tabsize=8, a tabset of 1,9 would be equivalent -- with
tabs above "9" being "9-1" or every 8th column above 9.
Otherwise y
Reuti wrote:
To avoid that this gets broken, I would suggest to use a modified syntax like
1,9,30,34,/4 for using a width of 4 beyond 34.
It wouldn't be broken. The syntax would become the same as on
other platforms. As it is now, it is already incompatible. The point
is to make
Are there other utils that rely on tabs to align
output as much as 'du'?
What would be objections to fixing 'du' or others
that rely on such?
Paul Eggert wrote:
L A Walsh wrote:
Are there other utils that rely on tabs to align
output as much as 'du'?
Sure. 'ls', 'fmt', 'cut', 'cat', 'pr',
What would be objections to fixing 'du' or others
that rely on suc
Paul Eggert wrote:
L A Walsh wrote:
I'm working on some loose ends, but basically,
First, it would default to providing no change. ;-)
Through use of a switch it can expand the tabs to spaces
using a default of every 8th column (after 1) (using a
switch value of 'ExpandTo').
Paul Eggert wrote:
L A Walsh wrote:
The idea would be to have it be transparent. Adding
on various output filters is hardly transparent.
Nor is having behavior depend on environment variables.
---
The behavior isn't dependent on environment variables.
The behavior is sel
Paul Eggert wrote:
On 01/28/2017 10:13 PM, L A Walsh wrote:
This is already a problem
Of course. All I am saying is that we should not make it worse.
---
"Do as I say, not as I do?"
Wasn't 'ls' just change recently? You can come
up with arguments that it
Paul Eggert wrote:
L A Walsh wrote:
'ls -C'.
---
Doesn't work.
It works for me.
---
Ah, I tested it the wrong window where I
hadn't unset LS_OPTIONS... If only this was
all "automatic" like locale settings or choosing
terminal-specific color codes...
In reading Gnu's Coding Standards (
https://www.gnu.org/prep/standards/standards.html#Non_002dGNU-Standards),
Under non-Gnu-Standards -- it is specifically talking about POSIX
compatibility when it says:
In particular, don’t reject a new feature, or remove an old one,
merely because a stand
Eric Blake wrote:
tag 25817 needinfo
thanks
On 02/20/2017 01:41 PM, L A Walsh wrote:
So... why should 'rm' not be able to start it's deletion
from the inside of a directory? (@ "." )?
Please give more details as to what you think is broken. Instead of
descri
Or are you arguing that contents within the directory should be removed,
even though the directory itself cannot be?
---
That's the way a recursive descent algorithm
works: it processes the contents, before the parents.
When it gets to the parent, it couldn't remove it, but
due to th
Eric Blake wrote:
the discussion here is about an early exit
on an attempt to remove '.', which, contrary to your claim, appears to
always have been in POSIX as far as I can tell (and even if it has not
always been in POSIX, the fact that I can quote a 20-year-old document
that describes curre
Sven Joachim wrote:
,
| EXDEV oldpath and newpath are not on the same mounted filesystem.
| (Linux permits a filesystem to be mounted at multiple
| points, but rename() does not work across different mount
| points, even if the same filesystem is mounted
Bernhard Voelker wrote:
On 03/02/2017 10:16 PM, L A Walsh wrote:
Anyone know why Linux doesn't do detection by device vs.
by mount point? Both pieces of info have their use, but for rename
seems that 'by device' would be optimal.
quick guess: because not only the device
Kyle Sallee wrote:
Thanks for the fast response.
Right or wrong POSIX is POSIX,
Yet a LF as part of a line does seem worth counting.
A line must terminate with a line feed.
Yet a string does not require a line feed.
how is that important? Sort sorts lines, not strings.
but for actua
The new format uses extra spacing on columns where it isn't needed --
but the extra space isn't enough to handle the 1 file that was quoted
(needs 5 extra columns). Where does it get '3' (and why doesn't it use
2?)?
Here are 32 files:
ls
aaa bbb ccc ddd eee
Pádraig Brady wrote:
On 19/05/17 07:48, L A Walsh wrote:
The new format uses extra spacing on columns where it isn't needed --
but the extra space isn't enough to handle the 1 file that was quoted
(needs 5 extra columns). Where does it get '3' (and why doesn't
Needing to hardlink some files from tree1 to tree2, I
had them in a script and @first used:
"cp -lv":
cp -lv src/a dst/a
'src/a' -> 'dst/a'
Later, I thought to use 'ln -v' for a different tree:
ln -v src/a dst/a
'dst/a' => 'src/a'
Wait a sec.. I'm not linking from dst/a
to src/b, bu
Was composing a response to this and started getting
a headache. Erg.
in short, 'ls' is the way it is because the listing
puts the files in the 1st column (& in symlink case,
puts target on right).
'ls' creating terminology for cp/mv/ln, is really a case
of the tail wagging the dog.
how to
Paul Eggert wrote:
pavan kumar yalavarthi wrote:
" *touch -* " is not working i.e., file named " - " is not being
created
It's not a bug. In coreutils, 'touch -' is documented to touch the
standard output file, not a file named '-'. The POSIX specification
for 'touch' allows either the core
Paul Eggert wrote:
L A Walsh wrote:
"Touching the 'file' associated with stdout"?
Yes, that's it.
How would I (or someone) use it?
You run "touch -". Whatever file stdout happens to be associated with,
gets touched. It's the same idea as "
Paul Eggert wrote:
L A Walsh wrote:
You run "touch -". Whatever file stdout happens to be associated
with, gets touched. It's the same idea as "cat -", except with stdout
rather than stdin.
The difference between that and updating due to write activity being
Two related things...
Tried to copy a dir from my linux Music folder to my portable player.
Linux uses XFS. Player uses VFAT.
Wanted to copy all available & supported meta info from source to dir,
cp -af
cp -a Valkyrja /l/
cp: preserving permissions for ‘/l/Valkyrja/folder.jpg’: Not suppor
Dmitry V. Levin wrote:
It's a security limit rather than a fixed buffer, see e.g.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=da029c11e6b12f321f36dac8771e833b65cec962
Hmm, original poster had about 2.3MB of data.
The patch referenced above says to limit ar
(Originally posted w/2 separable issues merged: splitting.)
In copying to a directory from a file system that has no unix
permission bits (from one that does), one gets many duplicate
error messages. Ex, copying from from a standard linux file
system to a VFAT FS, cp reported:
cp -a Valkyrja
I typed stat -t to look at the terse form of 'stat', and see
a bunch of numbers -- but nowhere do I see what those numbers
are suppose to be (i.e. they aren't documented in the manpage
and they obviously aren't the same as what is in the non-terse display).
when I display 'stat', it displays fields my platform doesn't know
about.
Utilities "shouldn't" display fields that are specific to other platforms.
Specifically, I'm not aware of a linux (or, for that matter, a POSIX)
"Birth time". Things are confusing enough w/o adding in other platform
info,
Assaf Gordon wrote:
Hello,
On 2017-10-09 12:59 PM, L A Walsh wrote:
I typed stat -t to look at the terse form of 'stat', and see
a bunch of numbers -- but nowhere do I see what those numbers
are suppose to be (i.e. they aren't documented in the manpage
and they obviously are
Bernhard Voelker wrote:
> On 10/09/2017 09:38 PM, Assaf Gordon wrote:
> > Perhaps it's worth mentioning in the help-screen/man-page that the
> > full format is available in info/online ? What do others think?
>
> IMO this is sufficient:
>
> $ man man/stat.1 | grep Full
>Full documentati
I executed a command:
nice --19 sleep 5
and hoped to get back a status as to whether or not I was
allowed to use a negative priority, since on Windows,
anyone in the Admin group can set a priority, with
the above command running sleep at 'High' priority, but
on linux:
nice --19 sleep 1
nice
Paul Eggert wrote:
L A Walsh wrote:
how do you tell if the resetting of the
priority worked or failed?
I guess you're supposed to look at stderr, which is what you did.
This is the way 'nice' has behaved for quite some time, and it's what POSIX
specifies. We'd n
If one does a 'cp -rl' -- one gets a coyp of the tree...sorta,
with file hardlinked, and with directories getting their own set
of inodes because:
can't be hardlinked -- so no hardlinking (even if worked, wouldn't make
a separate copy) &&
can't have softlinked dirs, as to softlink something, you n
Paul Eggert wrote:
L A Walsh wrote:
Like I'll want an "RCS" dir to point to 1 RCS tree -- so I try to use
ln . ln, of course seems to think I
want the impossible -- and says you can't have hard-linked directories.
You can use "ln -s" instead of plain &qu
Original Message
Subject: bug#32127: RFE -- in the way "cp -rl" -- enable 'ln' to do
likewise?
Resent-Date:Thu, 12 Jul 2018 07:17:02 +0000
Resent-From:L A Walsh
Resent-CC: bug-coreutils@gnu.org
Date: Thu, 12 Jul 2018 00:16:50 -0700
F
Paul Eggert wrote:
On 07/12/2018 02:16 AM, L A Walsh wrote:
I'm asking why does 'ln' bother to tell the user that they are
wrong and do nothing useful? Why not just go ahead and create a symlink
The user didn't ask for a symlink, and it sounds unwise for ln to be
Paul Eggert wrote:
On 07/12/2018 02:16 AM, L A Walsh wrote:
I'm asking why does 'ln' bother to tell the user that they are
wrong and do nothing useful? Why not just go ahead and create a symlink
The user didn't ask for a symlink,
User didn't ask for a physica
Bernhard Voelker wrote:
I disagree here: some people are not that familiar with the differences
between symlinks and hardlinks, okay, but the consequences for using either
type may be quite dramatic later on.
I am not suggesting handing out alternates when you have a
choice. I
Michael Stone wrote:
On Tue, Jul 17, 2018 at 01:25:59AM -0700, L A Walsh wrote:
I am not suggesting handing out alternates when you have a
choice. I'm suggesting doing something useful in a case where there are
no alternates and no downsides. If you can come up with a case wh
Michael Stone wrote:
On Tue, Jul 17, 2018 at 02:15:14PM -0700, L A Walsh wrote:
I can't think of a similar failure mode that I'd want a hard link
created
Yes, you've made that clear
---
I think you are making it clear that you didn't
understand what I said an
Mike Hodson wrote:
I wager that some people *aren't* aware that you cannot hardlink a directory
If they don't know why, they probably don't know the difference
between hard and soft links to files -- and will *then* be annoyed that
linking doesn't work. *THEN*, they will your "
Michael Stone wrote:
Or, they expect the traditional behavior, which is that requesting a
link which can't be created will result in failure. You seem to
completely disregard the possibility that any script written in 40 years
might use that behavior in its logic, while I find it extremely
Pádraig Brady wrote:
+This function does not support arguments outside of the range of the
+unsigned char type in locales with large character sets, on some platforms.
+OS X 10.5 will return non zero for characters >= 0x80 in UTF-8 locales.
---
According to Unicode, characters 0x80-0x9F ar
Created following test dir (as seen by tree) in /tmp
tree mybin
Ishtar:/tmp> tree mybin
mybin
├── iptool -> alt-tool #broken link
├── iptool-restore -> iptool #broken link
├── iptool-save -> iptool #broken link
└── usr
└── mybin
├── alt-tool
├── iptool -> alt-t
Was looking to see when the underlying filesystem
changed in a path.
I used:
stat -f -c%f /
821
stat -f -c%i /var
822
There are way too many zeros, not to mention being left justfied
with zeros.
What I might expect to see is more like this:
821
or
822
mountpoint -d shows the
On 11/7/2018 11:22 AM, Bernhard Voelker wrote:
On 11/7/18 5:07 PM, L A Walsh wrote:
Was looking to see when the underlying filesystem
changed in a path.
I used:
stat -f -c%f /
821
stat -f -c%i /var
822
sorry, I overlooked the %i example:
---
Both should be %i
I have a bunch of files numbered from 1-over 2000 without leading zeros
(think rfc's)...
They have names with a non-numeric prefix & suffix around the number.
It would be nice if sort had the option to ignore non-numeric
data and only sort on the numeric data in the 'lines'/'files'.
Yeah, I can
On 11/13/2018 6:44 PM, Eric Blake wrote:
On 11/13/18 8:32 PM, L A Walsh wrote:
I have a bunch of files numbered from 1-over 2000 without leading zeros
(think rfc's)...
They have names with a non-numeric prefix & suffix around the number.
It would be nice if sort had the option to i
On 11/14/2018 12:27 AM, Erik Auerswald wrote:
Hi,
On Tue, Nov 13, 2018 at 06:32:55PM -0800, L A Walsh wrote:
I have a bunch of files numbered from 1-over 2000 without leading zeros
(think rfc's)...
They have names with a non-numeric prefix & suffix around the number.
Are prefix a
On 11/6/2018 10:48 AM, Assaf Gordon wrote:
On 2014-08-01 3:38 a.m., Schleusener, Jens wrote:
I am not sure if it's a bug or not but for my application cases the
"sort" command with use of the very helpful option "-V" (natural sort of
(version) numbers within text) not always delivers the by
The reason I was confused about the output -- is that
it really is messed up. (3-3-3-0-3)
On 11/8/2018 6:19 AM, Bernhard Voelker wrote:
On 11/8/18 11:53 AM, L A Walsh wrote:
Both should be %i for the file system ID in hex.
How is it that the fs ID is the same as the device
number of the
Recently there was some discussion on inconsistencies in
how version sort worked and some people *basically*, said:
"it's not our fault, it's Debian's algorithm, you wanna
change it, convince them."
Um...fine. Except that it is a Gnu tool, not a Debian tool,
meaning that if one is going to
Over the past few years I have has for the ability to set
defaults for my system regarding various behaviors in
coreutil programs. Some of the these behaviors have been
regulated via ENV vars in the past, but I was told that this
was not desirable as gnu was trying to get away from using
ENV vars
So undocumented features are considered wishlist items
in Gnu?
On 12/18/2018 12:04 AM, Assaf Gordon wrote:
tags 33786 notabug
severity 33786 wishlist
retitle 33786 doc: sort: document Debian's version-sort algorithm
stop
Hello,
On 2018-12-18 12:11 a.m., L A Walsh wrote:
meaning th
I wouldn't consider debian to be a standards organization.
Perhaps they should get their version sort adopted by POSIX?
But having algorithms that read:
use ascii sort for this field if after a character in this list [].
but use numeric sort for this field if after this list [].
but use an inde
'gnu.conf', so that users can know to pay attention to
it. Notice I'm naming it 'gnu.conf' and not coreutils.conf -- I'm
not intending this to be limited to coreutils.
On 12/20/2018 1:59 PM, Paul Eggert wrote:
On 12/17/18 11:12 PM, L A Walsh wrote:
I find th
The below methods cannot alter or fix the problems that require
a configuration file.
Example: have 'rm -fr .' do a depth first removal and not
pre-inspect any argument before its children.
Whether or not to expand tabs in output so that output to
a terminal that doesn't have tabstops every 8
Features where their non inclusion was unable to be met due to
pre-existing usage and where using or allowing behavior change based
on ENV vars was disallowed due to new gnu policies to minimize usage
of ENV vars. At the time config files were mentioned as a possible
solution but at the time I wa
On 12/20/2018 5:21 PM, Assaf Gordon wrote:
If you are requesting such features (or others)
It's best to start a new thread for each topic.
They've already been discussed and ignored because there was no
way to add the feature for a default behavior other than
ENV vars or a config, both
On 12/23/2018 5:46 PM, Paul Eggert wrote:
Similarly with 'find'
"find" is not part of coreutils, and discussion of it should be moved to
a separate bug report, which you can create by emailing bug-findut...@gnu.org.
If you were discussing whether or not each each county or province i
On 12/20/2018 5:21 PM, Assaf Gordon wrote:
For example,
If there was an "rm --depth-first" feature,
you could enable it easily with "alias" - right?
---
If you would ensure that this is possible, you would have
my gratitude. However, it is not the case. The algorithm USED to
be dept
On 12/31/2018 4:23 AM, Assaf Gordon wrote:
Hello,
On 2018-12-31 4:36 a.m., L A Walsh wrote:
On 12/20/2018 5:21 PM, Assaf Gordon wrote:
If there was an "rm --depth-first" feature,
---
If you would ensure that this is possible, you would have
my gratitude.
There seem
On 1/11/2019 1:20 AM, Assaf Gordon wrote:
> tags 15328 notabug
> close 15328
> stop
>
> Hello,
>
> On 2013-09-10 3:01 p.m., Linda Walsh wrote:
>> Whatever the problem is, it's not in 'mv'...
>
> Given the above, and no further comments in 5 years,
> I'm closing this item.
There w
and it is not on the manpage, but tar copies
acls and has them on the manpage.
It guess it is an oversite that cp copies over 'xattrs'
but not acls?
On 1/18/2019 12:32 AM, Assaf Gordon wrote:
> retitle 12400 rmdir: add --one-file-system option
> severity 12400 wishlist
> tags 12400 wontfix
> stop
>
>> If you want a recursive option why not use 'rm -rf'?
>>
-
rmdir already provides a recursive delete that can cross
file system bounda
1 - 100 of 166 matches
Mail list logo
