2021-02-01 00:59:35 +0700, Robert Elz via austin-group-l at The Open Group:
[...]
> | As most of the remaining issues are with $'\u' and $'\U', I
> | would suggest that it be dropped for issue8 for now.
>
> what is the "it" you're suggesting dropping (or deferring)?
>
> The whole
2021-06-29 16:28:17 +0200, Vincent Lefevre via austin-group-l at The Open Group:
[...]
> > (
> > sleep 1
> > set +o errexit -o xtrace
> > pwd
> > pwd
> > ) | :
> >
> > Calls pwd only once with most shell implementations (all those
> > where pwd is builtin).
> >
> > Is that allowed?
>
>
2021-07-02 09:31:11 +0100, Geoff Clare via austin-group-l at The Open Group:
> Stephane Chazelas wrote, on 01 Jul 2021:
> >
> > BTW, for "expr", what is "zero" meant to be?
> >
> > I see some variation in behaviour for "00", " 0
2021-07-02 10:08:52 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
[...]
> It's a common problem in practice
[...]
expr has so many design flaws, maybe the best approach would be
to remove it from the standard altogether.
In practice, it can't be used reliably, and it's mos
Is:
printf '%s\n' a,b a,a | sort -c -t, -k1,1
Meant to succeed or not?
It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a
confusing:
sort: -:2: disorder: a,a
diagnostic and succeeds in NetBSD.
It succeeds with -s in all implementations that support that
flag (all but Solaris
2021-07-02 14:07:17 +0200, Joerg Schilling via austin-group-l at The Open Group:
> "Stephane Chazelas via austin-group-l at The Open Group"
> wrote:
>
> > Is:
> >
> > printf '%s\n' a,b a,a | sort -c -t, -k1,1
> >
> > Meant to succeed or not?
&g
2021-07-02 15:54:48 +0100, Geoff Clare via austin-group-l at The Open Group:
> Joerg Schilling wrote, on 02 Jul 2021:
> >
> > > > > sort: -:2: disorder: a,a
> > > >
> > > > Try to use the POSIX sort variant to avoid the message.
> > > [...]
> > >
> > > I suppose you mean the -C option, which
> >
2021-07-01 14:35:03 +0100, Geoff Clare via austin-group-l at The Open Group:
[...]
> The -v option is only in the Issue 8 drafts. It looks like we missed
> the need for a change to the EXIT STATUS section when it was added.
> I'd suggest adding to the description of exit status 0:
[...]
So in the
2021-07-01 11:45:40 +0100, Geoff Clare via austin-group-l at The Open Group:
[...]
> The standard says nothing about internal buffering; it just requires
> pwd to write the directory to file descriptor 1. It also states that
> exit status 0 means "successful completion".
[...]
> If an implementor
2021-07-01 15:24:58 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
[...]
> So in the same vein should expr's specification be changed from:
>
> 0
> The expression evaluates to neither null nor zero.
[...]
BTW, for "expr", what is "zer
2021-07-01 16:03:59 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
> 2021-07-01 15:24:58 +0100, Stephane Chazelas via austin-group-l at The Open
> Group:
> [...]
> > So in the same vein should expr's specification be changed from:
> >
> > 0
> &
2021-06-28 17:28:04 +0700, Robert Elz via austin-group-l at The Open Group:
[...]
> A more blatant case would be
>
> pwd | (exit 0)
[...]
On the zsh mailing list, where the issue was initially brought
up by Vincent, there was also the mention that EBADF error was
explicitly ignore as a
2021-06-28 12:06:34 +0100, Geoff Clare via austin-group-l at The Open Group:
[...]
> > It has been tradition, for a very long time, for writes on stdout to
> > have errors ignored - particularly in a case like this, where because
> > of the redirection, stdout is probably buffered, and not a lot
2021-06-28 20:01:03 +0700, Robert Elz:
[...]
> steph...@chazelas.org said:
> | On the zsh mailing list, where the issue was initially brought up by
> | Vincent, there was also the mention that EBADF error was explicitly
> | ignore as a special case, as some systems have or used to have
> |
2021-06-29 09:49:40 +0100, Geoff Clare via austin-group-l at The Open Group:
[...]
> > If in general, then forget it - the users would lynch you (you'd probably
> > suicide first) if you successfully caused that to happen.
>
> No they wouldn't. The only reason to set SIGPIPE to be ignored is
>
2021-07-04 15:47:55 +0700, Robert Elz via austin-group-l at The Open Group:
> Date:Fri, 2 Jul 2021 14:41:50 +0100
> From:"Geoff Clare via austin-group-l at The Open Group"
>
> Message-ID: <20210702134150.GB16587@localhost>
>
> | I've always assumed that the
2021-07-04 15:47:55 +0700, Robert Elz via austin-group-l at The Open Group:
[...]
> which is the way it should be - if one has taken the trouble to specify
> what parts of the record are the keys for sorting (and -u comparisons)
> then sort should not be gratuitously adding more - that it used to
2021-07-03 18:43:40 -0700, Michael Forney via austin-group-l at The Open Group:
[...]
> I'm working on an implementation of the pax tool, and am looking
> for some clarification of how (if at all) the -s option should
> interact with symlink targets.
[...]
See also:
2021-07-04 07:21:08 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
[...]
> Note that the equivalent --transform in the GNU implementation
> of tar lets you specify whether to apply the transformation to
> {sym,hard}links or not with flags.
[...]
Actually, libarchive
2021-04-16 14:07:01 +0100, Martijn Dekker via austin-group-l at The Open Group:
> Op 15-04-21 om 22:43 schreef Harald van Dijk:
> [...]
> > In specific cases, the shell may be able to detect that these issues
> > cannot be a problem. In those specific cases, the optimisation should be
> >
2021-04-10 22:12:47 +0200, Joerg Schilling via austin-group-l at The Open Group:
> "Jan Hafer via austin-group-l at The Open Group"
> wrote:
>
> > For a short recap why: There are `which, type, command, whence, where,
> > whereis, whatis, hash` used in shells. Worse, the semantics of `which`
For the record, see the interesting discussions on the zsh
mailing list from when that feature was added there almost
exactly 20 years ago:
https://www.zsh.org/mla/workers/2001/msg02715.html
https://www.zsh.org/mla/workers/2001/msg02716.html
https://www.zsh.org/mla/workers/2001/msg02740.html
2021-09-10 22:46:26 +0100, Stephane Chazelas via austin-group-l at The Open
Group:
[...]
> I've personally used the feature to reorder items in sets, so
> would object to precluding reusing arguments.
[...]
As mentioned on that mailing list and it's still undocumented,
-r can be used with
2021-09-11 00:04:20 +0200, Joerg Schilling via austin-group-l at The Open Group:
> "Stephane Chazelas via austin-group-l at The Open Group"
> wrote:
>
> > For the record, see the interesting discussions on the zsh
> > mailing list from when that feature was ad
2021-09-11 00:29:44 +0200, Joerg Schilling via austin-group-l at The Open Group:
[...]
> > As mentioned on that mailing list and it's still undocumented,
> > -r can be used with print -f to disable reuse:
>
> The problem, POSIX defines printf(1) to not handle options. So I don't think,
> we
2021-09-11 01:55:56 +0200, Joerg Schilling via austin-group-l at The Open Group:
[...]
> So the main problem I see is that the option -r is probably not usable anymore
> because ksh's builtin print(1) implements -r for a different purpose.
[...]
2001-10-18 15:15:34 +0100, Oliver Kiddle:
[...]
>
2021-10-22 01:11:43 -0500, Rob Landley via austin-group-l at The Open Group:
[...]
> > > Where system("-blah") fails because sh is insane legacy weirdness and it
> > > turns
> > > out that -c does NOT take an argument. So:
> > >
> > > sh -c -i "echo hello"
> > >
> > > Works, which that means
2021-10-30 22:01:51 +0700, Robert Elz via austin-group-l at The Open Group:
> Date:Fri, 29 Oct 2021 18:13:29 -0700
> From:Alan Coopersmith
> Message-ID:
>
> | The SVR4 implementation (inherited by Solaris & illumos) writes white
> | space before each pid to
I'll just voice my opinion on this matter:
That system("-x") doesn't run "-x" is a (minor) bug. I don't
think anyone would argue with that. On historic Unix systems,
it's a regression introduced by a change of API of the sh
utility.
POSIX ended up mandating that bug (mandating that system("+c")
2021-10-30 10:45:36 +0100, Geoff Clare via austin-group-l at The Open Group:
[...]
> No. It _allows_ stdout to be just the digits, but it also allows
> each pid to be surrounded by characters (see %d in XBD
> chapter 5).
[...]
About that, I see for instance this example in the resolution of
2021-10-22 12:43:11 +0300, Oğuz:
[...]
> > So system() was broken when sh started accepting more than one
> > option argument.
> >
>
> I wouldn't say broken. This is rather an academic case, I don't see why
> anyone would name a utility that way (`-potato'/`+potato'), I don't know a
> single
2021-11-03 17:06:07 +0100, Vincent Lefevre via austin-group-l at The Open Group:
> On 2021-10-30 14:33:04 +0100, Stephane Chazelas via austin-group-l at The
> Open Group wrote:
> > POSIX ended up mandating that bug (mandating that system("+c")
> > should run an in
2023-09-03 08:27:58 +0700, Robert Elz via austin-group-l at The Open Group:
[...]
> The SysIII echo (abomination) can be done using printf %b independant
> of IFS:
>
> echo() { printf '%b ' "$@"\\n\\c; }
>
> works.
Nice, though has the same limitation as my bash echo -e "$*\n\c"
$ echo()
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
2023-10-20 02:19:41 +0700, Robert Elz via austin-group-l at The Open Group:
[...]
> and even earlier, I started to consider what the relationship should be
> between shell variables, and shell built-in utilities.
[...]
I remember bringing that up a few years ago here.
See
2023-10-23 11:02:10 +0100, Geoff Clare via austin-group-l at The Open Group:
> Robert Elz wrote, on 22 Oct 2023:
[...]
> > Too far back for me to remember. I can't access that with any browser
> > I have installed, which doesn't include lynx or anything similar, and
> > haven't done anything
2022-10-31 10:35:38 -0700, Scott Lurndal via austin-group-l at The Open Group:
[...]
> Historically, '[[' was implemented directly by the shell, while '['
> was implemented using fork(), exec("[").There is clearly a benefit
> to eliminating process creation.
[...]
AFAIK and as also suggested
2023-01-10 10:07:11 +, Geoff Clare via austin-group-l at The Open Group:
[...]
> I'll reopen the bug and propose new wording there.
[...]
Thanks. Do you think adding the -r option, to not execute the
command on empty input as already implemented by many xargs
implementations could be added as
2023-01-10 13:38:13 +, Stephane Chazelas via austin-group-l at The Open
Group:
[...]
> I agree it's only remotely related but:
>
> find ... -print0 | ... | xargs -r0 cmd
>
> is the common idiom (and the equivalent of find -exec cmd {} +)
> and it would be awkward to s
2023-01-09 16:20:13 +, Austin Group Bug Tracker via austin-group-l at The
Open Group:
[...]
> On page 3365 line 114593 section xargs (DESCRIPTION),
[...]
> If the -0 option is specified, the application shall ensure that
> arguments in the standard input are separated by null bytes.
[...]
2022-12-08 15:39:32 +, Austin Group Bug Tracker via austin-group-l at The
Open Group:
[...]
> It is looking like the group might decide to add find -print0 and related
> xargs and read features (for reasons I won't go into here).
[...]
That's good news. Would you go over those reasons here
2022-12-08 17:31:54 +, Geoff Clare via austin-group-l at The Open Group:
[...]
> > Is there any plan of adding the accompanying -z options of
> > grep/sort/ls/sed/cut... (see also the --files0-from of some GNU
> > utilties or the awk -v RS='\0' -v ORS='\0' that some awk
> > implementations
[...]
> On page 3106 line 105084 section read (SYNOPSIS),
> change:read [-r]
> var...to:read [-r] [-d
> delim] var...
[...]
About read -d, when stdin is a terminal device, I find that all of
ksh93, zsh and bash (not mksh) do the equivalent of "stty
-icanon" at least. ksh93 also sets eol to the
2022-10-31 12:00:24 -0700, Scott Lurndal via austin-group-l at The Open Group:
[...]
> However, another benefit of the '[[' builtin is that it does not
> do word splitting or pattern expansion.
[...]
"[" doesn't do word splitting of pathname expansion either, it's
the shell that does if you
2023-03-12 14:04:55 -0400, Lawrence Velázquez via austin-group-l at The Open
Group:
[...]
> > What happens (exit status etc) if there's a write error while writing that
> > output?
>
> % /opt/local/libexec/gnubin/true --version >&-; echo "$?"
> true: write error: Bad file descriptor
2023-11-20 17:30:32 +, Austin Group Bug Tracker via austin-group-l at The
Open Group:
[...]
> On page 2920 line 97596 section find (-newer), change:The
> primary shall evaluate as true if the modification time of the current file
> is more recent than the modification time of the file named
52 matches
Mail list logo
