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
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
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-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 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-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 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-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-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: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 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-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
[...]
> 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
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-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-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 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
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-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
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
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
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-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-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-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-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-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 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-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
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-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-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 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-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-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-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
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 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
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-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-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 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-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-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-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-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 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-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`
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
2020-06-28 16:26:19 +0100, Stephane Chazelas:
[...]
> See below for comments (mostly minor) on the XBD [Definitions] section.
[...]
Following up with the next section (XBD 4 General concepts):
> 2724 4.8 Filenames
> 2725 Uppercase and lowercase letters sha
2020-06-25 11:53:19 +0100, Andrew Josey:
[...]
> The review period for 202x Draft 1 commences June 25 2020 and
> completes on August 25 2020. This is a committee review.
[...]
> All interested parties are invited to review these comments
> and submit comments directly to the Austin Group. Please
2020-06-14 16:00:58 +0200, Martijn Dekker:
> I am now the maintainer of what is currently, to the best of my knowledge,
> the only actively developed fork of AT ksh93. It is based on the last
> stable AST version, 93u+ 2012-08-01. Along with a few others I have been
> fixing a bunch of bugs. See
2020-05-30 02:16:18 +0700, Robert Elz:
> Date:Fri, 29 May 2020 18:02:24 +0100
> From: Stephane Chazelas
> Message-ID: <20200529170224.ul27advxyfyeh...@chazelas.org>
>
> | Why?
>
> It is kind of the definition... the numbered fd's ar
2020-05-29 22:40:27 +0700, Robert Elz:
> Date:Fri, 29 May 2020 14:59:48 + (UTC)
> From:shwaresyst
> Message-ID: <58121613.1659567.1590764388...@mail.yahoo.com>
>
> | Isn't there something about stdin, stdout, and stderr being required to
> | reference the
2020-03-11 09:55:57 -0400, Chet Ramey:
> On 3/11/20 5:43 AM, Stephane Chazelas wrote:
>
> > AFAIK, bash and bosh are the only shells that complain when you
> > use return outside of functions/sourced scripts (bash also
> > doesn't exit upon that failing "return"
2020-03-11 18:42:48 +0700, Robert Elz:
[...]
> | f() (
> | foo || return
> | ...
> | )
> |
> | are common.
>
> Really? I have only rarely ever seen (aside from the occasional one
> I write myself) sub-shell functions like that very rarely.
I certainly use it and have seen it
2020-03-11 15:38:10 +0700, Robert Elz:
> Date:Wed, 11 Mar 2020 06:37:41 +
> From: Stephane Chazelas
> Message-ID: <20200311063741.wpkuiffb7jsyv...@chazelas.org>
>
> | What shell implementation "ignores" the return or &q
2020-03-11 13:25:40 +0700, Robert Elz:
[...]
> What a return (or break or continue) in a subshell environment (but
> not in a function or dot script (or loop for break and continue) in that
> subshell does is unspecified. Some shells make it equivalent to exit,
> others ignore it, and others
IMO,
the best and only reasonable way to address it is to specify
what all shells do: return works like exit when called in a
subshell.
In
f() (
foo || return
bar
)
that return should be guaranteed to exit the function (with
foo's exit status) if foo fails.
It's also important to keep the
2020-02-19 11:52:21 +0100, Joerg Schilling:
[...]
> > $ zsh -c 'time -p uname | cat'
> > zsh:1: command not found: -p
>
> BTW: I remember that you frequently write that zsh intends to emulate the csh
> behavior, but csh _is_ able to get timing for builtin commands:
>
> csh
> % time alias
> 0.0u
2020-02-18 14:50:50 +0100, Joerg Schilling:
[...]
> There however is a shell that has massive problems: "zsh".
> zsh cannot time functins or builtins at all
Zsh's "time" keyword reports *process* resource usage (for each
component of the timed pipeline).
If there's no process, there's nothing
2020-02-18 11:31:54 +0100, Joerg Schilling:
[...]
> There is an official and documented way already, call:
>
> time -p command1 | command2
>
> The time utility in POSIX requires to use the -p option to be specified.
> Otherwise, the results are unspecified.
>
> All shells I am aware
2020-02-04 19:56:05 +0700, Robert Elz:
[...]
> What I am at the very least unclear about, is that the way that this
> group chose to require "--" processing, appears to me to also require
> that any arg (before that "--" or an arg not starting with "-") which
> does start with "-" be treated as an
2020-02-03 15:10:29 -0800, Don Cragun:
[...]
> "The search for a matching sequence starts at the beginning
> of a string and stops when the first sequence matching the
> * ``begins earliest in the string’’. If the pattern permits
> * a variable number of matching characters and
2020-02-03 14:32:57 +0100, casper@oracle.com:
[...]
> Right. I think it may need some fine tuning but I think it is fine to
> avoid the shell when it is not needed.
Yes, at least (beside what's already done):
- that optimisation must be disabled if the first word is a
builtin, special
2020-02-03 12:40:45 +0100, Joerg Schilling:
[...]
> > It looks like it's caused by an "optimisation" in its
> > libc:exec*(), so /usr/xpg4/bin/sh and POSIX are not to blame
> > after all.
>
> To which Solaris version does this apply?
That was 11.4
> > $ ksh -c 'printf %d 1+1'
> > printf: 1+1
2020-02-03 11:43:38 +0100, Joerg Schilling:
[...]
> > $ /usr/xpg4/bin/sh -c 'type printf'
> > printf is a shell builtin
>
> This does not apply to OpenSolaris, but on OpenSolaris, this was closed
> source
> as ksh88 is not available under OSS license.
>
> This also does not apply to Oracle
2020-02-01 10:47:46 +, Stephane Chazelas:
[...]
> That doesn't explain why it's different with ${0+type} or when
> there's more than the one invocation of "type" in the script.
[...]
OK, I see what's going on.
It looks like it's caused by an "optimisation" in its
2020-01-31 21:26:33 +, Stephane Chazelas:
[...]
> You might have been mislead by Solaris' /usr/xpg4/bin/sh
>
> On Solaris 11,
>
> $ /usr/xpg4/bin/sh -c 'type printf'
> printf is a shell builtin
>
> But
>
> $ truss -ft execve /usr/xpg4/bin/sh -c 'printf "
2020-01-24 15:14:48 +0100, Joerg Schilling:
[...]
> > > printf "$(gettext 'Hello World %2$d %1$d')\\n" 1 2
> > >
> > > to be able to control the order of the output of arguments in a way that
> > > is
> > > specific to the target language. ...
> >
> > > BTW: this extension is also available
2020-01-31 11:43:17 +0100, Joerg Schilling:
[...]
> > That would break things like:
> >
> > sed "s/.$//"
> >
> > sed "/^$/d; s/$foo/$bar/g"
>
> I see no problem with using:
>
> sed ",^$,d; s,$foo,$bar,g"
That is also unspecified as per POSIX but that was not my point.
My point is that adding
2020-01-30 10:37:57 +, Austin Group Bug Tracker:
[...]
> # echo $/ $?
> INT 130
[...]
While having an unambiguous and complete representation of the
exit status of the last command is a good idea (rc, es, akanga
are other shells that do it), $/ is not a very good choice of
variable name IMO.
2019-09-26 16:28:27 +, Schwarz, Konrad:
[...]
> POSIX should disallow `:' and `]' in character class names.
[...]
While I would not disagree with that, I don't think POSIX
prevents implementations from using [[:foo:]] for other things
than character classes so that would not be enough to
2019-09-25 22:29:36 +0100, Harald van Dijk:
[...]
> 1a. Invalid character classes:
>
> case x in [x[:bogus:]]) echo x ;; esac # bash,bosh,mksh,nbsh,osh,zsh
> case x in [![:bogus:]]) echo x ;; esac # above except osh
[...]
See also
2019-09-25 10:22:07 +0100, Geoff Clare:
[...]
> I wrote the above before I had fully thought it through, and having slept
> on it my preference is now much stronger, and I certainly would object to
> specifying the NetBSD sh behaviour. The reason is because treating
> backslash differently in
2019-09-24 15:53:07 +0100, Geoff Clare:
[...]
> to:
>
> 3. If a specified pattern contains any '*', '?' or '[' characters
>that will be treated as special (see [xref to 2.13.1]), it shall
>be matched against existing filenames and pathnames, as
>appropriate. Each
2019-09-24 12:24:43 +0100, Geoff Clare:
[...]
> > In NetBSD sh, backslash is given this special treatment only if the current
> > pathname component of the pattern includes a metacharacter. That is, an
> > indirect /de\v/nul[l] does not find /dev/null, but an indirect /d[e]\v/null
> > does.
>
>
2019-09-24 09:46:27 +0100, Geoff Clare:
[...]
> > Regardless, the above question applies in
> >
[...]
> var='\*'
[...]
> > printf '%s\n' */$var
> >
> > Or
> >
> > printf '%s\n' $var/*
>
> Those both have a * that will be treated as special, so matching
> against existing files is performed. The
2019-09-23 15:39:49 +, Austin Group Bug Tracker:
[...]
> On page 2384 line 76271 section 2.13.3, change:3. Specified
> patterns shall be matched against existing filenames and pathnames, as
> appropriate.to:3. If a specified pattern contains
> any '*', '?' or '[' characters that will be
2019-08-22 09:50:56 +0100, Geoff Clare:
[...]
> So how about:
>
> If a returned ASSIGNMENT_WORD token begins with a valid name,
> assignment of the value after the first to the name
> shall occur as specified in [xref to 2.9.1]. If a returned
> ASSIGNMENT_WORD token does not
Hello,
is there anything in the spec that would say that
!(true&)
is not guaranteed to be interpreted the same as
! (true&)
?
It works in all shells but ksh (ksh88, ksh93 and pdksh) where
!(true) conflicts with the !(pattern) extended negation globbing
operator (it conflicts with zsh
2019-08-21 11:29:09 +, Austin Group Bug Tracker:
[...]
> I don't like the suggestion of making it completely unspecified how
> non-name=... is parsed. All of the examples you give are things that I
> would naturally expect to be parsed as some kind of assignment if they are
> not treated as a
2019-08-08 17:30:28 +0100, Geoff Clare:
> Stephane Chazelas wrote, on 08 Aug 2019:
> >
> > 2019-08-08 15:39:18 +0100, Geoff Clare:
> > []
> > > I have repeated it with /bin/sleep instead of sleep. It still treated the
> > > whole AND-OR list as one jo
2019-08-08 15:39:18 +0100, Geoff Clare:
[]
> I have repeated it with /bin/sleep instead of sleep. It still treated the
> whole AND-OR list as one job:
>
> $ { /bin/sleep 3 | /bin/sleep 4; /bin/sleep 1 | /bin/sleep 2; } && {
> /bin/sleep 5; /bin/sleep 6; }
> ^Z[1] + Stopped
2019-08-08 11:43:53 +0100, Geoff Clare:
[...]
> I tested a complex (although not as complex as yours) AND-OR list in
> ksh93 and it treated the whole thing as one job:
>
> $ { sleep 3 | sleep 4; sleep 1 | sleep 2; } && { sleep 5; sleep 6; }
> ^Z[1] + Stopped { sleep 3 | sleep 4;
2019-08-08 10:21:14 +0100, Geoff Clare:
[...]
> A bigger issue with bg, in shells that treat each pipeline in a
> foreground AND-OR list as a separate job, is that if one of those jobs
> is stopped and then placed in the background, what happens to the
> remainder of the AND-OR list? For example:
2019-08-07 10:31:38 +0100, Martijn Dekker:
> Op 07-08-19 om 09:40 schreef Geoff Clare:
> > It seems that bash has a rather nasty bug here, as can be seen in the
> > following:
> >
> > $ sleep 5 || true && echo foo
> > ^Z
> > [1]+ Stopped(SIGTSTP)sleep 5
> > foo
> > $ fg
> > sleep 5
[...]
2019-08-01 15:51:10 +0100, Geoff Clare:
> Stephane Chazelas wrote, on 01 Aug 2019:
> >
> > It's also not clear what the interaction between GLOB_MARK and
> > GLOB_NOCHECK would be. If a pattern expands to itself because it
> > can't find a match, should it still call
2019-07-27 10:49:39 +, Austin Group Bug Tracker:
[...]
> > If, during the search, a directory is encountered that cannot
> > be opened or read and errfunc is not a null pointer, glob()
> > calls (*errfunc()) with two arguments.
> [...]
> > 2. The eerrno argument is the value of errno
2019-08-01 09:42:10 +0100, Geoff Clare:
> The glob() part probably needs further
> discussion.
[...]
Note that I've references this discussion on the musl mailing
list https://www.openwall.com/lists/musl/2019/07/31/8
They were already working at fixing the stat() instead of
lstat() issue.
One
2019-07-30 15:31:13 +0100, Geoff Clare:
[...]
> It's not invention because the standard already requires it. (It also
> requires EACCES, ELOOP, ENAMETOOLONG, ENOENT, ENOTDIR to be treated as
> errors. The question is which ones the standard should be changed to
> say are ignored.)
[...]
By that
2019-07-30 14:29:23 +0100, Geoff Clare:
[...]
> > Do you have a better suggestion?
>
> Unless one of the implementations changes to do something better
> before we get too far into work on Issue 8, I think the only
> choices we have are the Solaris behaviour, the GNU/BSD behaviour,
> the GNU/BSD
2019-07-30 20:18:43 +0700, Robert Elz:
[...]
> If a sys call executed by glob while searching fails, then it should treat
> that exactly the same as ENOENT (the thing simply doesn't exist for glob
> purposes) and continue with whatever is next.
[...]
While I generally agree for bugid:1275 -- for
2019-07-30 11:27:15 +0100, Geoff Clare:
[...]
> > For ENOENT, that can be seen as a pathological case worth
> > reporting as well, especially in the */*.c case where the
> > current directory contains broken symlinks.
>
> That's inconsistent with your position on ENOTDIR.
>
> If regfile exists
2019-07-30 10:48:49 +0100, Geoff Clare:
[...]
> The odd thing about all these implementations that ignore ENOTDIR and ENOENT
> (or don't but think they should), is that they are not following either of
> the possible interpretations of the current text.
>
> If they want to interpret it literally
2019-07-29 22:25:29 +0100, Stephane Chazelas:
> 2019-07-29 21:33:50 +0100, Stephane Chazelas:
> [...]
> > BTW, what's the point of 2.10.2 7a? It seems 7b already says
> > what 7a says (if the TOKEN doesn't contain a =, then rule 1
> > applies). The distinction seems to be c
2019-07-29 21:33:50 +0100, Stephane Chazelas:
[...]
> BTW, what's the point of 2.10.2 7a? It seems 7b already says
> what 7a says (if the TOKEN doesn't contain a =, then rule 1
> applies). The distinction seems to be caused by the distinction
> between cmd_name vs cmd_word grammar
1 - 100 of 357 matches
Mail list logo
