That typical usage example in the info page for dircolors:
eval `dircolors [OPTION]... [FILE]`
(see
http://savannah.gnu.org/cgi-bin/viewcvs/*checkout*/coreutils/coreutils/doc/coreutils.texi?rev=1.233
@example
eval `dircolors [EMAIL PROTECTED]@dots{} [EMAIL PROTECTED]
@end example)
is not
When watchnig a file by name with tail -F, if read permissions
are removed, tail stops watching even though it has a file
descriptor open on the file.
With inotify:
$ : file
$ tail -F file
[1] 20796
$ exec 3 file
$ echo 1 3
1
$ chmod 0 file
tail: %
head).
I don't think IN_DELETED_SELF is useful in follow-name mode
either, but I've not removed it.
--
Stephane
From f97355fa31f5e13f95667a50908506388d62df64 Mon Sep 17 00:00:00 2001
From: Stephane Chazelas stephane.chaze...@gmail.com
Date: Tue, 3 Feb 2015 21:22:06 +
Subject: [PATCH] tail: fix
2015-05-11 23:50:25 +0200, Jo Drexl (FFGR-IT):
Hi guys,
I had to write a Windows bat file for twentysomething users and - as
Linux geek - wrote a small Bash script for it. The code in question is
as follows:
echo -e net use z: srv\\aqs /persistent:no /user:%USERNAME%
$BG_PASSWD\r
[...]
2015-05-11 17:36:50 -0600, Eric Blake:
On 05/11/2015 04:14 PM, Pádraig Brady wrote:
echo -e net use z: srv\\aqs /persistent:no /user:%USERNAME%
$BG_PASSWD\r
'echo -e' is non-portable. POSIX recommends that you use printf
instead, as the POSIX version of echo is supposed to behave
2015-06-04 14:06:03 -0600, Eric Blake:
[...]
+$ @kbd{cat Makefile}
+list =
+bad:
+ @@for arg in $(list); do echo $$arg; done
+good:
+ @@list='$(list)'; for arg in $$list; do echo $$arg; done
[...]
Another option is to use:
for arg in $${-+$(list)}; do echo $$arg; done
That's
2015-06-04 16:32:48 -0600, Eric Blake:
On 06/04/2015 02:59 PM, Eric Blake wrote:
+good:
+ @@list='$(list)'; for arg in $$list; do echo $$arg; done
[...]
Another option is to use:
for arg in $${-+$(list)}; do echo $$arg; done
Furthermore, your suggestion mishandles a list
2015-06-04 16:51:49 -0700, Paul Eggert:
Eric Blake wrote:
Actually, POSIX_does_ allow for missing words between 'in' and the
terminator (; or newline) before 'do' (whether by a word that expands to
nothing, or by omission of words), requiring that the body of the for
statement is skipped in
2015-06-05 09:43:10 +0100, Stephane Chazelas:
2015-06-04 16:51:49 -0700, Paul Eggert:
[...]
Ah, sorry, I was thinking of previous versions of POSIX, which
required at least one word after the 'in'. You're right, the
current POSIX version doesn't require this any more. So the Solaris
sh
2015-06-08 11:16:37 +0200, Erik Auerswald:
[...]
FWIW I use 'sort' to sort IPv4 addresses in my ping_scan[1] script.
The info documentation for sort provides another example, log files
sorted by IP address and time stamp. That specific example even needs
two runs of sort, because sort lacks
2015-06-08 12:43:32 +0200, Erik Auerswald:
[...]
I'm not even sure having a tool just for that specific task
would make sense though. Here, it sounds more like a job for a
high level language like perl/python... (what if I want to sort
on roman numerals now, week day names, astrological
2015-06-08 07:28:25 +0800, 積丹尼 Dan Jacobson:
On (info (coreutils) seq invocation) perhaps mention if one needs to
use two % items, a for loop might be required,
$ for i in `seq 14484 1 34484`; do printf %d=0x%x\\n $i $i; done
14484=0x3894
24484=0x5fa4
34484=0x86b4
[...]
Running
2015-06-08 11:16:37 +0200, Erik Auerswald:
[...]
FWIW I use 'sort' to sort IPv4 addresses in my ping_scan[1] script.
The info documentation for sort provides another example, log files
sorted by IP address and time stamp. That specific example even needs
two runs of sort, because sort lacks
2015-06-08 08:14:20 -0600, Eric Blake:
On 06/08/2015 05:14 AM, Stephane Chazelas wrote:
Maybe there's a way to allow that without having to implement
the specifics in sort.
Like sort key flags to invoke commands:
sort '-k1,1|ip2hex' '-k2,2n|roman2int' '-k3,3|iconv -t us
2015-06-03 14:33:35 +0100, Pádraig Brady:
On 03/06/15 14:20, Federico Alves wrote:
I think that shuf should have an option, may set ON by default, to avoid
empty lines in a file when shuffling it. if a file has 100 lines and ten
are simply returns, 99% of the time I do not want an empty
2015-06-06 21:49:16 +0300, Valdis Vītoliņš:
Note, that UTF-8 characters can be counted by counting bytes with bit
patterns 0xxx or 11xx:
https://en.wikipedia.org/wiki/UTF-8#Description
So, general logic should be, that, if:
a) locale setting is utf-8 (e.g. LANG=xx_XX.UTF-8), or
b)
2015-06-17 10:24:13 +, Ed Avis:
% mkdir foo
% rmdir foo/.
rmdir: failed to remove ‘foo/.’: Invalid argument
% rmdir --version
rmdir (GNU coreutils) 8.23
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html.
This
2015-07-01 19:41:00 -0600, Bob Proulx:
[...]
$ a= ; echo $s | wc -l
1
[...]
No. Should be 1. You have forgotten about the newline at the end of
the command. The echo will terminate with a newline.
[...]
Leaving a variable unquoted will also cause the shell to apply
the split+glob
2015-06-29 16:31:00 +0100, Pádraig Brady:
[...]
When there is only one column and we go beyond 1 with the -f option, the
output remains the first column
$ echo test1 | cut -d' ' -f1
test1
$ echo test1 | cut -d' ' -f2
test1
$ echo test1 | cut -d' ' -f3
test1
That difference
2015-06-29 17:25:11 +0100, Pádraig Brady:
[...]
$ printf '%s\n' a:b c d:e | paste -d: - /dev/null | cut -d: -f2
b
e
Good point. Or to better support field ranges:
$ printf '%s\n' a:b c d:e | sed 's/^[^:]*$/:/' | cut -d: -f2-
b
e
[...]
Maybe better as:
$ printf '%b\n' a:b
2015-08-23 13:26:35 +0200, Erik Auerswald:
Hi,
On Sat, Aug 22, 2015 at 08:58:01PM -0700, Paul Eggert wrote:
Pádraig Brady wrote:
Also base64 -w0 has similar meaning.
I didn't know that, but I don't like that either. Utilities should
use an explicit representation for infinity, if
2015-06-30 13:05:38 -0400, Assaf Gordon:
[...]
One more thing: instead of 'du -s *', perhaps 'du -d1' would
work better (depending on your needs), as it will print sizes
used only by directories.
Yes, and it will also include hidden files/dirs and won't have
problems with filenames starting
2015-06-30 12:51:02 +0200, Erik Auerswald:
[...]
But more a more obvious problem is 'du -shc' seems to be coming up with
the wrong number -- i.e. 1.5+3.6 = 5.1, not 5.0.
That are probably rounding errors avoided by du, that hsort cannot avoid
anymore.
[...]
Also, du -c gives you the
Hello,
it seems on Linux, GNU tail -f uses inotify to check if data is
available even for those types of files where inotify doesn't
work.
For instance, when running:
tail -fn+1 /dev/tty
Then press 1ReturnCtrl-D2ReturnCtrl-D3Return4Return
$ tail -fn+1 /dev/tty
1
1
^D2
2
^D3
4
upon the first
2015-07-22 01:54:58 +0100, Pádraig Brady:
[...]
On 21/07/15 14:34, Paul Eggert wrote:
Thanks, that patch looks good, except for some nits. POSIX spells the
phrase
non-portable and we might as well be consistent. The --help lines would
look
better as:
-p, --processor
2015-10-06 10:01:15 -0600, Eric Blake:
> tag 21636 notabug
> thanks
>
> On 10/06/2015 04:49 AM, JameDam wrote:
> > I have a file which is named *“-l”*, and I use the wc to count the file,
> > undesirably wc requested the standard input rather than my file *"-l"*
> > ,although
> > I use it
2015-08-27 16:18:51 +0100, Pádraig Brady:
[...]
info page:
[...]
It's easy to miss that it's not `-d[FROM]` here. A note along
these lines could help:
Note that the FROM value can only be specified with the long
option from.
Done at:
2015-08-26 03:13:59 +0100, Pádraig Brady:
[...]
I notice both with and without inotify
there is a similar issue (for different reasons)
when multiple devices are specified:
tail ---dis -f /dev/tty /dev/tty
I.E. we generally can't deal with this case in either case,
though it probably
2015-08-27 00:05:49 +0100, Pádraig Brady:
[...]
$ split -n10 -a4 -d5 echo.txt
split: cannot split in more than one way
Try 'split --help' for more information.
where as using longer option for `-d` i.e. `--numeric-suffixes` works fine.
$ split -n10 -a4 --numeric-suffixes=5 echo.txt
Hello,
that's another multibyte issue, it may be known already but I
can't see it being referenced on debbugs.gnu.org.
$ locale charmap
UTF-8
$ expr é : .
2
$ expr é
That is, characters are correctly matched, but a number of bytes
instead of characters is returned.
Same problem with
$ expr
2015-12-10 10:40:30 -0700, Bob Proulx:
[...]
> In this instance the first thing I thought of when I read your dirname
> -f request was a loop.
>
>while read dir; do dirname $dir; done < list
"read dir" expects the input in a very specific format and
depends on the current value of IFS (like
2016-03-22 12:31:50 -0700, Paul Eggert:
[...]
> It might be helpful to have some other environment variable that
> meant "try to be strict about supporting only behavior required by
> POSIX", as one could use that to develop shell scripts that were
> more portable. However, that would be a lot of
2016-03-22 13:43:30 +0100, Ruediger Meier:
[...]
> Is there any good reason why coreutils true and false are not POSIX?
>
> man 1p true:
> OPTIONS
>None.
> STDOUT
>Not used.
>
> But coreutils true has --version and --help implemented. It needs
> >/dev/null redirection to
2016-03-02 11:17:17 -0500, Assaf Gordon:
[...]
> >-h, --human-readable
> > with -l, print sizes in human readable format (e.g., 1K 234M
>
> This is not a typo, it is the correct explanation.
> Using "-h" by itself (e.g. "ls -h") does not print sizes at all, neither
> exact
2016-03-22 15:39:52 +0100, Ruediger Meier:
> On Tuesday 22 March 2016, Stephane Chazelas wrote:
> > 2016-03-22 13:43:30 +0100, Ruediger Meier:
[...]
> Ok, but it must not use STDOUT and it must return 0.
> true --help may predict the future of the stars as long as it exits 0
&
Only arguing on the classification of this bug here.
Let's call a cat a cat. When something doesn't work as
documented, it's a bug, not a wishlist entry.
AFAICT, there's nothing in the GNU coreutils documentation that
states that pr only works on input that consists exclusively of
single-byte
2016-11-30 18:37:05 -0800, Paul Eggert:
[...]
> In the meantime if you could submit a patch for the
> documentation that should fix the immediate documentation
> problem.
[...]
What about:
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index cc85f22..6eb497b 100644
--- a/doc/coreutils.texi
2016-11-30 18:37:05 -0800, Paul Eggert:
> On 11/30/2016 03:30 AM, Stephane Chazelas wrote:
> >That can also be seen as a POSIX conformance bug
>
> Not really, as POSIX does not require support for UTF-8 (except in
> the pax utility, which is not part of coreutils).
[...]
POSI
2016-12-01 07:04:05 +, Stephane Chazelas:
> 2016-11-30 18:37:05 -0800, Paul Eggert:
> [...]
> > In the meantime if you could submit a patch for the
> > documentation that should fix the immediate documentation
> > problem.
> [...]
>
> What about:
[...
2017-10-29 23:16:50 -0700, Paul Eggert:
> Pádraig Brady wrote:
>
> >I suppose we could stat() and if that succeeds && !fifo, only then call
> >open() ?
> >Patch to do that is attached.
>
> Better is to use open with O_NONBLOCK, as this avoids interpreting the file
> name twice in the usual
Test case:
/tmp$ mkdir -p 1/2
/tmp$ sudo mount -o size=1M -t tmpfs x 1/2
/tmp$ sudo mount -o size=2M -t tmpfs y 1
/tmp$ mkdir 1/2
/tmp$ df -h 1/2
Filesystem Size Used Avail Use% Mounted on
x 2.0M 0 2.0M 0% /tmp/1/2
The Size is correct as that's obtained from statfs()
2017-10-30 09:53:01 -0700, Pádraig Brady:
[...]
> I pushed my change with the comments fixed up.
>
> I thought about O_NONBLOCK and O_PATH but thought these might not
> induce or wait for the auto mount to occur.
[...]
Note that:
df /dev/watchdog
as root still causes the system to reboot on
test case:
mkfifo p
df p
That hangs, unless you make "p" non-readable or some other process
has the fifo open in write mode.
The reason is that df tries to open the fifo in read-only mode,
according to comments in the source code so as to trigger a
potential automout.
That goes back to
Hello,
[reproduced with rm 8.30 and current git head on ubuntu 20.04 amd64]
Whilst trying to answer
https://unix.stackexchange.com/questions/505317/using-rm-one-file-system-to-only-delete-files-on-the-local-filesystem
I noticed that "rm -rf --preserve-root=all some-dir" was not race-free.
2023-09-01 07:13:36 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
> 2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> > In today's Austin Group call, we discussed the fact that printf(1) has
> > mandated behavior for %b (escape sequ
2023-08-31 15:02:22 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> The current POSIX says that %b was added so that on a non-XSI
> system, you could do:
>
> my_echo() {
> printf %b\\n "$*"
> }
That is dependant on the current value of $IFS. You'd need:
xsi_echo() (
IFS=' '
2023-08-31 10:35:59 -0500, Eric Blake via austin-group-l at The Open Group:
> In today's Austin Group call, we discussed the fact that printf(1) has
> mandated behavior for %b (escape sequence processing similar to XSI
> echo) that will eventually conflict with C2x's desire to introduce %b
> to
2023-09-01 09:44:08 +0300, Oğuz via austin-group-l at The Open Group:
> On Fri, Sep 1, 2023 at 7:41 AM Phi Debian wrote:
> > My vote is for posix_printf %B mapping to libc_printf %b
>
> In the shell we already have bc for base conversion. Does POSIX really
> have to support C2x %b in the first
2023-09-01 07:15:14 -0500, Eric Blake:
[...]
> > Note that in bash, you need both
> >
> > shopt -s xpg_echo
> > set -o posix
> >
> > To get a XSI echo. Without the latter, options are still
> > recognised. You can get a XSI echo without those options with:
> >
> > xsi_echo() {
> > local IFS='
2023-09-01 07:54:02 -0500, Eric Blake via austin-group-l at The Open Group:
[...]
> > Well in all case %b can not change semantic in the bash script, since it is
> > there for so long, even if it depart from python, perl, libc, it is
> > unfortunate but that's the way it is, nobody want a semantic
2023-09-01 23:28:50 +0200, Steffen Nurpmeso via austin-group-l at The Open
Group:
[...]
> |FWIW, a "printf %b" github shell code search returns ~ 29k
> |entries
> |(https://github.com/search?q=printf+%25b+language%3AShell=code=Sh\
> |ell)
> |
> |That likely returns only a small subset of
"wc -c" without filename arguments is meant to read stdin til
EOF and report the number of bytes it has read.
When stdin is on a regular file, GNU wc has that optimisation
whereby it skips the reading, does a pos = lseek(0,0,SEEK_CUR)
to find out its current position within the file, fstat(0) and
On 2023-02-05 20:59, Paul Eggert wrote:
On 2023-02-05 11:59, Pádraig Brady wrote:
[...]
Let's leave that as-is, please. If 'wc' can output the correct value
without reading its input, POSIX does not require 'wc' to do the read,
and it seems perverse to modify 'wc' to go to the effort to refuse
Tags: patch
My bad, the patch was incorrect, it should have said
"replaced by the corresponding device major and minor numbers as two decimal
numbers separated by a comma and at least one space.", as
there's not always only once space between the major and minor.
See also
Package: coreutils
Version: 9.4
Tags: patch
The ls documentation currently doesn't state that for device
files, the size field in the long listing format is replaced by
major, minor.
Patch attached.
--
Stephane
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 8a2104831..c8e3bd110
55 matches
Mail list logo
