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
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
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 have
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
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 byt
n 2021/08/11 00: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/1
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 /usr
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 manpag
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 m
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 t
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 page
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 loo
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 proj
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 manpag
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 c
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 vali
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, in a
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 ema
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 mi
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 cross-device
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 --version
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,
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),
among
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?
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 bac
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 foo
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 '
gned as tools to aid, assist,
simplify and empower 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 -e
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,
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
https://www.gnu.org/software/coreutils/manual/html_no
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
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 p
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 fol
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:
>
> >
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 exten
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 for
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 comm
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 sugges
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 mi
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 POSIX_C
diverged at https://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 &#x
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 a
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
> m
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 bee
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 ch
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 outpu
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 guarantee
real bugs that came 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,
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 //s
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 o
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
directorie
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:
https://pubs.opengroup.org/onlinepubs/9699919799.
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 GMT
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 directories
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. I
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
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
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 digit
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
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 w
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 dept
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:
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
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
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
'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
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
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
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
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
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
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
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/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
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/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
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
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
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
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
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:
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
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
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
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
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
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:
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
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:
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
1 - 100 of 166 matches
Mail list logo
