On 2022/08/23 00:30, Mike Jonkmans wrote:
que
find is the path to go.
Because find isn't part of coreutils?
find isn't consistent either:
find . -name \*.foo
gives you output from dir ".", but you have to edit the output or add
other args to
get just the filenames, since there is
Try 'command pwd --version'
On 2021/09/19 16:09, william wrote:
coreutils version 8.32
The commands
pwd --version
and
pwd --help
return
pwd: bad option: -v
pwd: bad option: -h
On 2021/08/20 11:31, Paul Eggert wrote:
On 8/20/21 10:40 AM, L A Walsh wrote:
I wanted it just to work
So use 'stat -c "%s %n"'. That works just fine. 'stat' is a good tool
for this job, and there's no need for yet another 'ls' option for this
rare use case.
stat do
On 2021/08/20 08:08, Paul Eggert wrote:
On 8/20/21 12:02 AM, L A Walsh wrote:
When I use "-b" in du (equivalent to '--apparent-size --block-size=1)
Previously in this thread you asked for "allocated space for a file on a
device", which is why I was talking about that
On 2021/08/18 08:39, Paul Eggert wrote:
Perhaps your request would be more clear if you gave a specific example
of what you want and why --block-size doesn't do what you want.
I wanted to use ls to list the size of files in bytes, and use
Binary prefixes K=1024, M=1024**2, G=1024**3 to
On 2021/08/17 16:00, Paul Eggert wrote:
That's different from displaying the size that would have been allocated
on a device with a block size of 1 byte. 'du' can't do what you
requested, any more than 'ls' can.
However you want to phrase it, with:
--block-size=SIZE
I want to
On 2021/08/15 21:36, Paul Eggert wrote:
On 8/15/21 9:26 PM, L A Walsh wrote:
I don't want to display the allocated size on the current device,
but the size that would be allocated on a device with block-size=1-byte.
There's no practical way for 'ls' to calculate that, as the kernel
On 2021/08/15 21:00, Paul Eggert wrote:
On 8/15/21 4:13 PM, L A Walsh wrote:
Hmm... for libc.so, ls -l shows 253 bytes
for -s, it shows '4' and w/block-size=1, it shows
4096...
Right. That is, those numbers look right.
But I'm specifying a block size of 1 byte, to determine
:40, Paul Eggert wrote:
On 8/10/21 11:56 PM, L A Walsh wrote:
Perhaps the '-s' option in ls could pay attention to
the user-specified block-size?
Doesn't it already do that?
$ ls -s libc.so
12192 libc.so
$ ls -s --block-size=1 libc.so
12484608 libc.so
On 2021/08/11 00:40, Paul Eggert wrote:
O
How can I find all perl source files under the
perl source tree sorted by size + displayed
w/binary-metric prefixes. I wanted to look for
a good sample for _some_ specific size (not sure
of the size until I'd looked through a few).
I got close using:
find -iname \*.pl |sed 's!./!!' |xargs
First stab at a script is really slow...
find dirs, then find all files in the dir:
There's gotta be a faster way...ug!
lastt=1
shopt -s lastpipe
find "$1" -depth -type d |
while read dr;do
t=$(find "$dr" -xdev -maxdepth 1 -mindepth 1 ! -name . -a ! -name ..
-printf "%T@\n" |
cut
I did a re-install-in-place on windows that reset the
dirtimes on all the dirs to the date I did the re-inst.
As a partial recovery, I want to be able to reset the date
to the time of the last modified file in the dir.
I thought to use:
du -s --time DIR
but it's not just showing (from
On 2021/06/30 08:53, Kamil Dudka wrote:
The proposed patch makes sure that the devlist entry seen the last time
is used for comparison when eliminating duplicated mount entries.
---
I'm a bit surprised that the devlists exported for NFS are the same
as for smb. How is that guaranteed? But
On 2021/06/11 00:37, Wolfgang Rohm wrote:
Hello.
Stat prints the device number, major and minor, in hex and decimal.
They are both 8bit numbers clamped together. While the hex number is
perfectly fine, the decimal doesn't respect how this number has come
to existence. There is no meaning in
On 2021/04/11 07:21, Pádraig Brady wrote:
On 09/04/2021 12:46, 積丹尼 Dan Jacobson wrote:
man ln says:
-r, --relative
create symbolic links relative to link location
-s, --symbolic
make symbolic links instead of hard links
Hard to tell from the man
On 2021/04/21 19:11, Paul Eggert wrote:
On 4/18/21 10:46 AM, Peter van Dijk wrote:
While the manual (but not the manpage) mentions the data loss, I
think it would be great if sort did not have this problem at all, and
I think the OpenGroup text also says it should not have this problem.
I
On 2021/04/21 19:11, Paul Eggert wrote:
On 4/18/21 10:46 AM, Peter van Dijk wrote:
While the manual (but not the manpage) mentions the data loss, I
think it would be great if sort did not have this problem at all, and
I think the OpenGroup text also says it should not have this problem.
I
On 2021/03/27 12:34, Glenn Golden wrote:
$ ls -fl dir1 dir2
will produce what the OP asked for.
--
Interesting. How can ls return the files in the order they
are on disk?
On 2021/03/26 14:03, Peng Yu wrote:
Hi,
When I try `ls -l dir1 dir2`, the order of dir1 and dir2 in the output
is not necessarily the same as the input. How to make it the same as
the input order? Thanks.
Use separate invocations of 'ls' to guarantee the order of output
of the arguments.
On 2021/03/25 08:36, Glenn Golden wrote:
Perl's perldoc(1) is more or less analogous in spirit to GNU's
approach based on info(1). The man pages contain quite a bit of
useful info, but do not purport to be exhaustive.
=
On 2021/03/25 08:05, Paul Eggert wrote:
Most free-software
On 2021/03/22 15:21, Bernhard Voelker wrote:
According to the GNU guidelines and to avoid double work, the man page of
the coreutils is essentially not much more than the output of --help.
---
It sure would be nice if GNU would join the *nix family and
put full documentation in the
On 2021/03/23 16:43, Dan Jacobson wrote:
Or (info "(coreutils) Backup options") should "admit" that "Numbered
backups need to be trimmed occasionally by the user, lest the fill up
the disk."
---
Perhaps a scheme, similar, or duplicating that in logrotate would
be useful where older versions
I thought to display 0 (or 0) for 1st arg by doing:
du -BY, as -B says I can list a unit for scaling, but for
-BY and -BZ I get:
du: -B argument 'Y' too large.
It doesn't even look to see how much space is used, it
immediately returns Y & Z are "too large".
Why are those suffixes listed as
Did anyone see this? Usually someone says something like
confirming it or asking for more info.
Is this a known bug and/or has it been seen before?
(slightly cleaned up report below)
Thanks!
On 2021/03/10 13:41, L A Walsh wrote:
Was trying to save disk space by linking duplicate files
On 2021/03/10 19:15, Kaz Kylheku (Coreutils) wrote:
Me too; but that doesn't validate the arguments like Emilio wants.
E.g.
mv --dry-run existing-file nonexistent-dir/ # error
mv --dry-run nonexistent-object somewhere # error
mv --dry-run object /another/filesystem # diagnostic
On 2021/03/10 15:21, Paul Eggert wrote:
Although his email did reencode those names into ISO 8859-1 which is
more likely to cause problems than cure them these days, it still
displays well on my MUA (Thunderbird) because its header said
"Content-Type: text/plain; charset=iso-8859-1". His
On 2021/03/10 14:09, Glenn Golden wrote:
Second, minor, side rant:
Would be nice if more attention was paid to fixing mailers encoding
"Pádraig" and "Bénézech" as "P�draig" and "B�n�zech"
If you see substitute encodings like that, it strongly suggests the problem
is your MUA, not
On 2021/03/07 03:20, Emilio Garcia wrote:
Hi all,
I checked out the coreutils repo on Github and I would like to ask you
to add a dry-run option in the mv command.
When I've needed such functionality, I insert an 'echo'
before the 'mv' command, so in a script:
cmd=eval
if
Was trying to save disk space by linking duplicate
files, in a dir.
FWIW, my 'cp', is aliased to 'cp --preserve=all'
for f in Roboto*.ttf;do
cp -l /usr/share/fonts/TTF/$f .
done
cp: cannot create hard link './Roboto-Bold.ttf' to
'/usr/share/fonts/TTF/Roboto-Bold.ttf': Invalid
On 2021/03/10 06:50, Glenn Golden wrote:
Pádraig, Philippe, Paul -
Pádraig Brady [Tue, 9 Mar 2021 19:51:45 +]:
On 09/03/2021 12:58, Philippe Bénézech via GNU coreutils Bug Reports wrote:
Dear maintener,
I found a reproducible bug in df utility, installed in debian stable
$ df
On 2021/03/08 19:58, Paul Eggert wrote:
On 3/8/21 6:29 PM, L A Walsh wrote:
Warning, '-f' assuming '-r' was intended
I don't think that'd be helpful, given that -f now has a well-defined
and common meaning that doesn't agree with what you remember, and that
in 4.2BSD (circa 1983) -f
On 2021/03/08 18:04, Paul Eggert wrote:
I don't know which version of touch I remember it from as I've
use a few versions of unix, as in (scratching memory):
some form of SCO Unix on Intel chips (early 80's, pre IBM-PC), HPUX, Sun
Unix(a BSD variant), SunOS (a SysV variant), IRIX(sgi),
On 2021/03/08 18:04, Paul Eggert wrote:
On 3/8/21 5:50 PM, L A Walsh wrote:
Data loss shown in original bug submission. As mentioned/documented
it was use of:
'touch -f '
Sure, but what was the context of that command? Was it part of a shell
script? What was the script for? Can we see
On 2021/03/08 16:07, Paul Eggert wrote:
On 3/8/21 3:27 PM, L A Walsh wrote:
gnu accepts but ignores the previously active '-f'(from) switch
GNU "touch -f" has always been a no-op and has never meant "from" as far
as I know - though I admit I looked back only to
gnu accepts but ignores the previously active '-f'(from) switch
and replaced it with '-r' to be compatible with posix, likely,
but created a meta-data loss case in that if someone
uses it:
ll foo bar
-rw-rw-r-- 1 0 Mar 8 14:33 bar
-rw-rw-r-- 1 0 Dec 10 2012 foo
Want to transfer D/T from
On 2021/01/27 00:15, Christian Groessler wrote:
What is so difficult with
$ echo "3" | sudo sh -c "cat > proc/sys/vm/dropcache"
I don't get it...
regards,
chris
well, if you have 'sh' it might work, but it also might
run some "rc" script.
In some cases I've seen some people have
On 2021/01/26 05:57, Rodney W. Grimes wrote:
> So, I would remove '-i, --input-stream'. (And if you think it's
> missing, maybe write a program to read from any FD and write to stdout.)
Its name is cat(1)
cat /dev/fd/# >outputfile
Except the problem, which I've run into before,
On 2021/01/26 17:40, Alex Henrie wrote:
Personally, I like the idea of only having to type `echo foo | tee -q`
instead of `echo foo > /dev/null`, so I think the patch indeed does
the right thing in that case.
Perhaps you didn't see it, but why would you want to write
tee -q, when 'tq' is
On 2021/01/21 05:17, Alejandro Colomar wrote:
This is useful for using tee to just write to a file,
at the end of a pipeline,
without having to redirect to /dev/null
Example:
echo 'foo' | sudo tee -q /etc/foo;
---
Isn't this what you want and shorter?:
echo 'foo' | sudo tq /etc/foo
ls
On 2021/01/21 07:15, Adalbert Hanßen wrote:
e.g. to/etc/bash.bashrc. However once this is done, calling
date -Iminutes
yields an error because the date format is stated twice. It would be
possible to unalias the alias by calling
\date -Iminutes
if one wants to let date deliver a shorter
On 2021/01/18 08:08, Bernhard Voelker wrote:
find(1) can also ... [various examples of find's usefulness elided]
Have a nice day,
Berny
===
As I stated in the original message:
On 2021/01/16 16:29, L A Walsh wrote:
Yes, you could do it some other way, like by using 'find
those who use such tools.
On 2021/01/17 14:18, Paul Eggert wrote:
On 1/16/21 4:29 PM, L A Walsh wrote:
Yes, you could do it some other way, like by using 'find'
That's what I'd do, yes. 'find DIR -depth -type d -exec rmdir {} +'. I
doubt whether it's worth hacking on this at the C level
Every once in a while, I want to remove what I believe to be
an empty directory tree, safely.
I wondered, why not have rmdir have a recursive option
that would remove all directories under a given directory,
presuming they were empty. That way I can try to remove
the tree, removing what it can,
On 2020/11/14 02:13, Michael J. Baars wrote:
On Fri, 2020-11-13 at 14:36 -0800, L A Walsh wrote:
On 2020/11/12 00:48, Michael J. Baars wrote:
Hi,
I needed to zero out my hard drive because one of my nodes has become unstable.
To this purpose I used coreutils dd with the following
On 2020/11/12 00:48, Michael J. Baars wrote:
Hi,
I needed to zero out my hard drive because one of my nodes has become unstable.
To this purpose I used coreutils dd with the following command line arguments
dd if=/dev/zero of=/dev/mmc... status=progress
and I noticed how slow this program is
Ah...so what I asked for has already been added in a newer version.
I seem to have > env --version
env (GNU coreutils) 8.26.18-5e871
What version of env should I try and test?
Thanks!
On 2020/11/04 08:09, Erik Auerswald wrote:
Please see
Rewriting this bug as the other one, apparently, was too unclear
to be understood.
This gives an example, two in fact.
On 2020/11/03 14:48, Bernhard Voelker wrote:
On 11/3/20 6:29 PM, L A Walsh wrote:
I tried to use 'env' to find perl in my path and wanted to pass
the -T option
On 2020/11/03 04:29, Bernhard Voelker wrote:
As you didn't give an example, it's hard for me to imagine what you
want to achieve, or better why current 'env' would "dislike it".
---
I tried to use 'env' to find perl in my path and wanted to pass
the -T option to perl.
/usr/bin/env
I wanted to pass a switch to an interp line, but 'env' seems to dislike it.
I also noticed that env ignores '--' to indicate end of switches that it
should
process.
How difficult would this be to do? Specifically,
allow double-dash ("--") to indicate the end of 'env' switches such
that any
On 2020/10/29 05:59, David Hesselbom wrote:
Dear coreutils maintainers,
Quoting rm.c itself:
enum interactive_type
{
interactive_never, /* 0: no option or --interactive=never */
interactive_once, /* 1: -I or --interactive=once */
interactive_always /* 2: default, -i or
On 9/8/2020 9:27 AM, Glenn Golden wrote:
The attached patchset addresses a minor issue with program behavior vs.
documentation of the df, du, and ls tools from coreutils-8.32, when using
the --si option.
It resurrects an issue that was brought up in 2014 [3] and eventually closed
in 2018 [4]
Yeah, I'd thought about asking for this as well, like as maybe a "rmdir -r"
or rmdir -rp
where either the want of recursion implied going up to ancestors (since
decending along a chain
of directories would be a bit indeterminent, or requiring a redundant '-p',
as well, as it would tell the program
I think that would work in my specific use case.
I can think of other use cases that it probably wouldn't, but I'm not going
to worry
about those right now. :-)
Thanks!
-l
On Wed, Jun 24, 2020 at 1:07 PM Andreas Schwab
wrote:
> On Jun 24 2020, L A Walsh wrote:
>
> > A second
I allocated a large file of contiguous space (~3.6T), the size of a disk
image I was going to copy into it with 'dd'. I have the disk image
'overwrite' the existing file, in place using "conv=nocreat,notrunc" (among
other switches) and that works with the final file still using max-sized
8GB
xterm-TrueColor
and xterm-24bit
I've heard of, but direct? Isn't that a direct serial line
connection?
But suffice it to say, I haven't seen any _concensus_ on a name
or terminal-name for that feature.
Certainly TrueColor or 24-bit (or maybe 32) would be more descriptive
that something used
xterm-TrueColor
and xterm-24bit
I've heard of, but direct? Isn't that a direct serial line
connection?
But suffice it to say, I haven't seen any _concensus_ on a name
or terminal-name for that feature.
Certainly TrueColor or 24-bit (or maybe 32) would be more descriptive
that something used
On 2020/01/29 01:58, Peng Yu wrote:
Hi,
For directories, ls shows in the time of the directory itself.
Sometimes, it is more important to show the latest time of files in
the directory in addition to the directory time.
Is there an easy way to show such information? Thanks.
You might
On 2020/01/20 04:14, microsoft gaofei wrote:
Many people suggest using dd to create bootable USB,
https://www.archlinux.org/download/ . But cp and mv also writes to USB, e.g., cp
archlinux-2020.01.01-x86_64.iso /dev/sdb, cat archlinux-2020.01.01-x86_64.iso >
/dev/sdb. Is it safe to use these
On 2019/11/28 04:39, Krzysztof Labus wrote:
> In the manual I see:
> The SIZE argument is an integer and optional unit (example: 10K is
> 10*1024). Units are K,M,G,T,P,E,Z,Y (powers of 1024) or KB,MB,...
> (powers of 1000).
>
> 1. Why df not using Ki, Mi, Gi etc. in powers od 1024 ??
>
---
On 2019/10/09 14:01, Mark Friedenbach wrote:
> I have a persistent problem that has caused me serious trouble in the
> past: I mixup 'rm' and 'mv'. I suspect this is because on my keyboard
> they are typed with the same fingers and muscle memory kicks in,
> especially if I just typed the other
On 2019/10/11 12:56, Paul Eggert wrote:
> On 10/11/19 11:20 AM, Pádraig Brady wrote:
>
>> if you want to exclude nested file systems like that,
>> you could try:
>>alias df='df -x squashfs'
>>
> On my Fedora 30 workstation that option doesn't make any difference.
>
--
I'd
On 2019/09/03 18:51, Pádraig Brady wrote:
> Yes we could be better here.
> Attached is a fairly simple improvement:
>
> $ time seq.new 1 1 1e8 >/dev/null
> real 0m1.516s
>
> $ time seq.new 1 2 1e8 >/dev/null
> real 0m0.834s
>
> $ time seq.orig 1 2 1e8 >/dev/null
> real 0m40.435s
>
> It
Was looking at some large sequences and the time they took
and found that while end-point only was fast:
declare -x TIMEFORMAT="%2Rsec %2Uusr %2Ssys (%P%% cpu)"
> time seq 1e8 >/dev/null
0.75sec 0.74usr 0.01sys (99.77% cpu)
Trying just to generate only odd numbers:
> time seq 1 2 1e8 >/dev/null
On 2019/08/02 23:10, Assaf Gordon wrote:
So when I look at the system call on linux for rename:
oldpath can specify a directory. In this case, newpath must
either not
exist, or it must specify an empty directory.
(complying with
bugs.gnu.org/36831#38 )
>
> For completeness, quoting your second message ( from
> https://bugs.gnu.org/36831#50 ):
>
> On 2019-08-02 9:56 p.m., L A Walsh wrote:
>> On 2019/08/02 19:47, Assaf Gordon wrote:
>>> Can new merging features be added to 'mv'? yes.
>>>
On 2019/08/02 19:47, Assaf Gordon wrote:
> Can new merging features be added to 'mv'? yes.
> But it seems to me these would be better suited for 'higher level'
> programs (e.g. a GUI file manager).
---
But neither the person who posted the original bug on this
nor I are using a GUI, we
Reposting this, since I realize that fixing the target-exists cases
with a helpful algorithm could change or eliminate many cases
where where now the user gets an error instead.
On 2019/07/28 23:28, Assaf Gordon wrote:
>
>
> $ mkdir A B B/A
> $ touch A/bar B/A/foo
> $ mv A B
>
On 2019/08/01 16:37, Paul Eggert wrote:
> Ulrich Mueller wrote:
>
>> Except for the surrogates
>> U+D800...U+DFFF, it looks like an arbitrary restriction
>>
>
> It's not entirely arbitrary. Because of the restriction, coreutils printf
> doesn't have to worry about what this command should
On 2019/07/28 23:28, Assaf Gordon wrote:
>
>
> $ mkdir A B B/A
> $ touch A/bar B/A/foo
> $ mv A B
> mv: cannot move 'A' to 'B/A': Directory not empty
>
> And the reason (as you've found out) is that the target directory 'B/A'
> is not empty (has the 'foo' file in it).
> Had this
This is a bit weird, as the hw-platform, apparently is i386 or i686, not
sure,
but the cpu is definitely accessible in /proc/cpuinfo.
The following text is from the sysctl call in the
kernel help text for the option:
CONFIG_SYSCTL_SYSCALL:
sys_sysctl uses binary paths that have been found
On 2019/07/15 00:01, hoffelm...@gmail.com wrote:
> Hi,
>
> I am using ls from the cureutils 8.31 on arch linux (5.2.0 x86_64) and
> think it has a bug/inconsistant in printing an file type indicator (-F)
> while using the long listing format (-l).
>
>
> If I use `ls -F ~` I get the following
On 2019/06/28 12:02, Eric Blake wrote:
> If your application layer is on top of Linux, then yes, the underlying
> OS guarantees that your application processing a path beginning with
> "//" is correct whether it preserves or shortens that path to "/".
Linux doesn't forever
erlying fs-drivers to r/w multiple full tracks
at a time while performing only 1 iop to write multiple tracks.
>
>
> -----Original Message-
> From: L A Walsh [mailto:coreut...@tlinx.org]
> Sent: vrijdag 28 juni 2019 13:15
> To: Marc Roos
> Cc: aglo; coreutils
> Subj
back and bit the project hard,
including bugs that were closed out because I hadn't sent them through
cygwin's list first when I knew they were not bugs in cygwin.
On 2019/06/28 08:38, Eric Blake wrote:
> tag ### notabug
> thanks
>
> On 6/28/19 6:11 AM, L A Walsh wrote:
>> rea
realpath -m //sysname/rootdir/.
returns "/sysname/rootdir" This is incorrect, according to POSIX.
and #3-4 have specific meanings in various applications that in usage.
1) leading double slashes are to be preserved
My Notes: in combining paths like pathcat(//, sys, /a) =>
should get
On 2019/06/06 09:25, Marc Roos wrote:
>
> Hmmm without being a maintainer. I would say cp -r is most used on
> single disk, so one thread is using the maximum disk iops taking y time
> to copy.
---
not exactly true, if the 1 disk as a 20 disk raid10.
You can target 10 areas at a time and
On 5/2/2019 11:49 PM, Denys Vlasenko wrote:
Gnu has a utility called parallel that _says_ it will ensure the
output is consistent with what you would get running
the command sequentially. Perhaps it would work for you? I haven't
used it extensively, so don't know or not, but thought I'd mention
On 5/1/2019 3:03 PM, Viktors Berstis wrote:
> When running "ls" or "ls -U" on a windows directory containing 5
> files, ls takes forever. Something seems to be highly inefficient in there.
>
---
it sounds like you are running ls with no options
(nothing in environment and no switches
On 4/29/2019 4:36 AM, David Ellenberger wrote:
> Dear maintainers
>
> I understand that admins have become accustomed to see 4096 in directories
> as it's consistent with the ls command and the technicality behind it.
>
---
Except that it isn't 4096 on all file systems. For empty
On 4/20/2019 6:54 AM, 積丹尼 Dan Jacobson wrote:
> (info "(coreutils) sort invocation") says
>
> ‘-i’
> ‘--ignore-nonprinting’
> Ignore nonprinting characters. The ‘LC_CTYPE’ locale determines
> character types...
>
@ location:
My console becomes 121 characters wide when I turn on
unicode, but stty says it is 132 characters.
Looking at the stty manpage, I see:
Special settings:
...
* cols N
tell the kernel that the terminal has N columns
* columns N
same as cols N
---
I thought
On 4/2/2019 6:23 AM, Maximilian Gleißner wrote:
> Hi,
>
> I have encountered a possible bug with the date function using both SuSE
> LEAP 15.0 and SuSE 10.2.
> This bug occurs when asking date for 'tomorrow' when there is a daylight
> saving timechange.
>
> Note: The machine is located in the
On 3/16/2019 9:07 AM, Bruce Dubbs wrote:
> It would be helpful to add a --terse option to df such that a user could
> do something like:
>
> DF=$(df -k --terse --output=used $PWD)
>
> Right now I see no method of omitting the header or to collapse the
> spaces between values to a single space.
On 3/3/2019 4:43 AM, Erik Auerswald wrote:
> Hi,
>
> On 3/3/19 09:40, L A Walsh wrote:
>
>> On 3/2/2019 11:31 AM, Bob Proulx wrote:
>>
>>> But regardless of that it does not change the fact that the entire
>>> purpose of read-only direc
On 3/2/2019 11:31 AM, Bob Proulx wrote:
> But regardless of that it does not change the fact that the entire
> purpose of read-only directories is to prevent removing and renaming
> of files within them.
>
But not by the user owning them. I don't remember the last time I used
chmod -w
On 2/26/2019 12:10 PM, Bob Proulx wrote:
>> rm -fr --one-filesystem foo/. or
>> cd foo && rm -fr --one-filesystem .
>
> rm: refusing to remove '.' or '..' directory: skipping '.'
>
> I agree with your complaint about "rm -rf ." not working. That is an
> annoying nanny-state restriction.
On 2/12/2019 3:05 AM, Ricky Tigg wrote:
> Hi. Suggestion: would auto-scaling regarding block sizes be a welcome
> feature to DD? Illustration by script (paths are valid for a *Linux Fedora*
> system):
>
auto-scaling to do what?
On 2/10/2019 1:52 PM, Bob Proulx wrote:
> L A Walsh wrote:
>>>> If you want a recursive option why not use 'rm -rf'?
>> rmdir already provides a recursive delete that can cross
>> file system boundaries
>
> Please provide an example. Something small. Som
On 2/10/2019 1:52 PM, Bob Proulx wrote:
> L A Walsh wrote:
>>>> If you want a recursive option why not use 'rm -rf'?
>> rmdir already provides a recursive delete that can cross
>> file system boundaries
>
> Please provide an example. Something small. Som
On 2/6/2019 1:36 AM, Ricky Tigg wrote:
> Enhancements request
> Hi. Command executed:
>
>
>- Could values reported at '(8.0 GB, 7.5 GiB)' be displayed using a two
>fractional digits accuracy (model 1.23 GiB).
>
Nah
Implies more accuracy than there is.
Use 2-3
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
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/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
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 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
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
On 12/13/2018 2:02 PM, Eric Blake wrote:
On 12/13/18 3:37 PM, Peng Yu wrote:
Hi,
`readlink` is faster than `realpath` for a large number of input
arguments. Note that the former starts slower than the latter. What
tricks is used in readlink to make it faster? Thanks.
Why don't you
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,
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
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
1 - 100 of 209 matches
Mail list logo
