2018-09-30 05:18:03 +0700, Robert Elz:
> Date:Fri, 28 Sep 2018 14:44:55 +0200
> From:Harald van Dijk
> Message-ID:
>
> | 1. Are the rules for determining the end of a dollar-quoted string
> | intended to be fully specified, especially when taking into account
>
2018-12-28 19:57:20 +, Harald van Dijk:
[...]
> Your shell and ksh are pretty much the only ones that do this. bash, dash,
> mksh, yash, zsh, they all print "not ok", because they parse dot scripts as
> a program, as is currently allowed, but under the proposed wording will not
> be.
[...]
I a
2018-12-31 06:51:13 +, Harald van Dijk:
[...]
> > Changing the value of LC_CTYPE after the shell has started
> > shall not affect the lexical processing of shell commands in
> > the current shell execution environment or its subshells.
[...]
Good find.
I wonder where that requirement comes fr
2019-01-03 03:29:31 +0700, Robert Elz:
[...]
> Now again, we know that the intent is that when we are forming
> that list of tokens, we will be doing alias processing on the first
> word of the alias value, recursively, as required - that's the way
> that shells work
[...]
Not necessarily on the *
2019-01-03 07:18:40 +0700, Robert Elz:
[...]
> This comment (mine here) is irrelevant, but that's another POSIX botch.
> Functions should be able to implement any command that can be implemented
> in the filesystem (provided one can write the code in a function to do
> the same thing, of course -
2019-01-03 03:29:31 +0700, Robert Elz:
[...]
> This wording does give rise to another problem however, what does
> "currently processing an alias" mean? According to the rest of the
> spec, all we do with an alias is replace the current word (with either
> the alias value, in the broken version,
2019-01-07 14:14:32 +0100, Joerg Schilling:
[...]
> > In any case, the spec should say "suitable for reinput *in the
> > same locale*". Even in shells like yash that don't support
> > changing the charset midway through its lifetime, you'll still
> > have problems if you replace ". ./file" with "sh
2019-01-09 04:38:15 +0700, Robert Elz:
[...]
> I don't know the history of aliases in sh (Joerg?)
[...]
AFAIK, the SysV shell never had aliases.
aliases come from csh which did not do that expansion after
trailing blank thing.
AFAIK, ksh is the shell that brought aliases to the Bourne-like
shel
One concern I have is that if I understand correctly, it
*allows* application to do:
alias 'while=until'
(though doesn't for other keywords like "{", "!")
and then *requires* implementations to expand "while" in
alias 'echo_expand=echo '
echo_expand while
and *requires* implementations *not* t
2019-01-09 18:24:47 +0100, Joerg Schilling:
[...]
> They also had the idea of implementing a shell builtin that behaves like:
>
> sh -c cmd args
>
> and thus could support parameterized macros.
[...]
That can only really be used for "parameterized macros" that
could be done as function
2019-01-10 04:00:37 +0700, Robert Elz:
[...]
> Nor can we tell the shells not to expand words that would be
> keywords when used elsewhere as currently users have the
> ability to do that, and we cannot break existing conforming
> applications.
[...]
It seems there's been a misunderstanding. I'm n
2019-01-14 14:32:25 +0100, Joerg Schilling:
[...]
> > I've tried all the shells I can get my hands on and I've found zero
> > examples of such a shell (except posh, which has removed alias suppport
> > altogether, but that doesn't count).
>
> posh does not work on platforms with a POSIX compliant
2019-01-15 11:56:20 +0100, Joerg Schilling:
[...]
> OK:
>
> PATH=/ /opt/schily/bin/posh -c 'type'
> /opt/schily/bin/posh: type: not found
>
> posh is s non-POSIX that even normal tests return incorrect results :-(
"type" is not in the POSIX base (and as a result not in
the Debian policy)
I
2019-01-15 16:13:42 +0100, Joerg Schilling:
> Stephane CHAZELAS wrote:
>
> > > posh is s non-POSIX that even normal tests return incorrect results
> > > :-(
> >
> > "type" is not in the POSIX base (and as a result not in
> > the Debi
2019-01-15 17:19:24 +0100, Joerg Schilling:
[...]
> > I don't think GNU/Debian systems care about XSI, or the UNIX
> > trademark either. AFAICT, they concern themselves with the POSIX
> > base, and pick XSI extensions when they are useful (and don't
> > break their own backward compatibility).
>
>
2019-01-15 17:19:24 +0100, Joerg Schilling:
[...]
> > Note that even UNIX (POSIX+XSI) certified systems are not
> > compliant. For instance, macOS "/bin/echo" doesn't expand \n,
> > \b... as POSIX+XSI requires.
>
> AFAIR, Apple did compile bash (like Sun did for Solaris) in a way that does
> not
2019-01-27 02:29:04 +, Harald van Dijk:
[...]
> This proposed resolution does not leave empty aliases (aliases not resulting
> in any token) unspecified. I mentioned them before, because they are
> mishandled by at least one shell:
>
> $ dash -c 'alias empty=
> empty'
> dash: 2: Syntax e
2019-01-28 08:08:53 +, Harald van Dijk:
[...]
> > alias ifdebug=
> > ifdebug echo DEBUG
> >
> > works fine in dash AFAICT.
>
> The non-DEBUG case is alias ifdebug=# to comment out the command.
>
> $ dash < > alias ifdebug=#
> > ifdebug echo DEBUG
> > EOF
> dash: 3: Syntax error: en
2019-03-01 06:37:15 +0700, Robert Elz:
[...]
> The same section also says
>
> 2. If the value of IFS is null, no field splitting shall be performed.
>
> but we do not make $@ expansions unspecified if IFS is null (more on
> that below.) The way that is done (the language required) is much
2019-05-28 16:39:30 -0700, Steven Penny:
[...]
> I think arrays are an important part of any language and should be considered
> for inclusion into the POSIX standard.
[...]
I agree arrays are essential in shells, I'd even argue it should
be the primary variable type there as that's what you manip
2019-05-30 19:05:33 -0500, Steven Penny:
[...]
> > Of all three designs zsh's is probably the best, but that's
> > mostly because it did fix that split+glob upon parameter
> > expansion issue of the Bourne shell (when not invoked as sh).
>
> This is where we differ (I think). I have had limited us
2019-05-31 06:43:14 -0500, Steven Penny:
[...]
> But you didnt really follow the Python example to conclusion. With Python (and
> most major programming languages) syntax is available to do something like
> this:
>
> import glob
> aa = glob.glob('*')
> if len(aa):
>print('foun
2019-05-31 20:34:05 +0100, Harald van Dijk:
[...]
> If there is, is there any plausible use case where the script would turn off
> that globskipdot option, rather than simply changing the pattern to cover .
> and .. explicitly? If a shell is in that globskipdot mode, it is simpler for
> a script au
2019-06-01 10:57:30 +0100, Harald van Dijk:
[...]
> (You have a typo in your first version, .[!.]* should be .[!.] like in your
> second version.)
Thanks. I swear I didn't do it on purpose to demonstrate that
it was impossible to get it right ;-).
It should actually be
..?* .[!.]* (as I did writ
2019-06-03 11:54:29 +0200, Joerg Schilling:
[...]
> > Some shells (mksh, pdksh, posh, zsh) already skip . and .. regardless of
> > what readdir() returns, even when invoked as sh.
>
> So these shells are not compliant and they will not give the expected result
> with:
>
> echo .*/Makefile
2019-06-04 15:12:11 +0200, Andreas Grapentin:
[...]
> # should probably include ../
> $ grep '#include' .*/*.{c,h}
[...]
Why?
Surely, the author intends that (if we assume a shell that
implements that csh-style {c,h} brace expansion) to look for
#include in the (non-hidden) c and then h files
2019-06-04 16:52:02 +0200, Joerg Schilling:
[...]
> The problem with the current situation and with the proposal from bug #1228
> is that there is neither a usable state, that a script can rely on, with the
> current nor with the proposed state.
>
> And even if the proposed change for bug #1228 w
2019-06-05 18:00:21 +0700, Robert Elz:
[...]
> mkdir a && cd a || exit 3
> case "$(echo .*)" in
> '. ..') exit 2;;
> . | ..) exit 1;;
> '' | '.*') exit 0;;
> *) echo "Strange glob!" >&2; exit 3;;
> esac
> )
> case "$?" in
> 3)echo "Sorry... No
2019-06-05 12:01:33 -0700, Jefferson Carpenter:
> Unlike path separation via basename and dirname, there is no
> utility to concatenate paths. The naive bash implementation:
>
>
>
> "${basename}/${dirname}"
>
>
>
> is not correct in the case that the basename is "//" (// ->
> ///), OR if
2019-06-05 13:16:14 -0700, Jefferson Carpenter:
> Not quite - if basename begins with one or more slashes that
> could still cause incorrect behavior.
>
> The closest would be echo ${dirname%/}/${basename##*(/)} with
> the bash extglob option enabled.
(note that's originally a ksh operator)
App
2019-06-06 15:59:33 +, Austin Group Bug Tracker:
[...]
> Change:The argument text shall consist of one or more
> lines. Each embedded in the text shall be preceded by a
> . Other characters in text shall be removed, and the
> following character shall be treated
> literally.to:The argument te
2019-06-07 23:39:51 -0700, L A Walsh:
> On 2019/06/05 02:06, Joerg Schilling wrote:
> > I believe that there is a
> > need to be able to check whether a shell hides "." and ".." from the glob
> > results.
> >
> How will you tell if that is the case, or whether or not the
> underlying OS hides (
2019-06-08 12:30:47 -0700, L A Walsh:
> On 2019/06/08 03:10, Stephane CHAZELAS wrote:
> > I beleive Joerg meant that we need a way to *ensure* that the
> > shell excludes "." and ".." from glob expansions.
> >
> > Otherwise:
> >
> > chmo
2019-06-10 08:46:57 +, Austin Group Bug Tracker:
[...]
> The changes arising from this bug were applied in POSIX.1-2008 TC2, so this
> is not the right place to request further changes. (All of the bugs tagged
> tc2-2008 should have been closed some time ago to prevent this situation
> arising.
2019-06-10 18:34:50 +, Austin Group Bug Tracker:
[...]
> IMO, after "asynchronous list" has been clearly defined as "AND-OR-list
> followed by &", and maybe renamed to "asynchronous AND-OR list", that whole
> paragraph should be changed to something like:
>
> } If job control is disabled (see
2019-06-11 17:57:30 +0200, Joerg Schilling:
> L A Walsh wrote:
>
> > On 2019/06/05 02:06, Joerg Schilling wrote:
> > > I believe that there is a
> > > need to be able to check whether a shell hides "." and ".." from the glob
> > > results.
> > >
> > How will you tell if that is the case, or w
2019-06-12 11:17:02 +0200, Joerg Schilling:
[...]
> But you finally conviced me to use "set -o globskipdot" as the new default.
[...]
Thanks for that.
> > But here, that's not even the case as you're synthesizing "." and
> > ".." when it's off which is a change of behaviour from the old
> > behav
2019-06-11 17:57:30 +0200, Joerg Schilling:
[...]
> The new code always hides the entries "." and ".." from readdir() and creates
> synthesized entries with "set +o globskipdot" (which is the default).
[...]
Would you also synthesize those entries for directories that are
not readable, or not sea
2019-06-14 11:16:56 +0100, Geoff Clare:
[...]
> > > 2. ex/vi
> > >
> > > Like for sed, the most widely used implementation of ex/vi (vim) does
> > > some special handling of \ inside bracket expressions. While, like I
> > > said in the bug description, [\t] does match on \ and t in compatibility
>
2019-06-14 12:21:58 +0100, Geoff Clare:
[...]
> > > FWIW, [\] doesn't work in /bin/vi, /bin/ex, /usr/xpg4/bin/vi,
> > > /usr/xpg4/bin/ex on Solaris either (it complains about an unmatched [
> > > there). It works in nvi or FreeBSD vi/ex or Solaris /bin/ed or
> > > /usr/xpg4/bin/ed
[...]
> Looks li
2019-06-14 13:41:15 +, Michael Greenberg:
[...]
> I'm unsure of what `getopts` should do to `OPTIND` when working with
> grouped options.
>
> Consider the following script:
>
> ```sh
> getopts "ab:c:" opt -ab hi -c hello ; printf "OPTIND=%1s opt=%1s OPTARG=%-5s
> ?=%d\n" "$OPTIND" "$opt" "$O
2019-06-15 00:44:02 +0700, Robert Elz:
[...]
> V='\.'
>
> case "$word" in
> \\$V) printf %s\\n "match: ${word}";;
> *) printf %s\\n "no match: ${word}";;
> esac
[...]
> context like a here doc, or uselesslly, arithmetic) in which case it is
> like everything
2019-06-15 06:49:27 +0700, Robert Elz:
[...]
> | And again, there is no such thing as a "pattern quoting char" in
> | most sh implementations including ksh88 (and all its
> | predecessors,
>
> You're right, there wasn't, but (perhaps by oversight, perhaps
> deliberately) it was added to the
2019-06-16 22:12:48 +0100, Stephane Chazelas:
[...]
> Well, yes, they now
> need to know that some shells treat unquoted \ specially in
> wildcards, so they need to escape it as well (with the same good
> old [x] but with [\\] in that case).
>
> So now my question is: which vari
2019-06-17 10:00:50 +0100, Geoff Clare:
> Stephane Chazelas wrote, on 16 Jun 2019:
> >
> > In
> >
> > files='\*x' sh -c 'ls -ld -- $files'
> >
> > We have an unquoted * in that unquoted $files. But here, if it
> > was going to be
2019-06-17 12:14:29 +0100, Geoff Clare:
[...]
> The standard clearly requires pathname expansion to be performed,
> using the pattern \*x
>
> If some shells don't bother to actually read the directory and do
> any matching operations, depending on the pattern contents, because
> they know that the
o -bc; echo
"$o"'
1
c
Expected:
1
b
I once wrote an implementation of a "getopts_long" as a POSIX
shell function to process GNU-style long options
(https://github.com/stephane-chazelas/misc-scripts/blob/master/getopts_long.sh)
It has a separate $OPTLPENDING variable to keep track of the
options in a given argument that are still to be processed.
--
Stephane
2019-06-17 15:22:25 +0100, Geoff Clare:
[...]
> > And all other implementations (including all the certified ones,
> > including kre's) should be deemed non-compliant?
>
> Yes.
[...]
So you would want to sacrifice backward compatibility, break
common usage patterns, force all implementations to b
2019-06-18 01:30:16 +0700, Robert Elz:
[...]
> However, there's another issue that ought be investigated:
>
> Consider
>
> mycmd() {
> unset myc_a_flag myc_b_flag myc_c
>
> while getopts abc:def: myc_opt
[...]
> }
>
>
> That, as it stands is fine, and th
2019-06-17 11:03:21 +0100, Stephane Chazelas:
[...]
> Those [1] to [11] points in my previous article identify 11
> differences and exceptions most of which POSIX will have to
> specify somehow if they want to allow all existing behaviours in
> that regard, or IOW to tell applicatio
2019-06-18 11:27:18 +0100, Stephane Chazelas:
[...]
> A [12] and [13] to add to the list (though it could just be a
> bug in bash):
[...]
$ a='\/' bash5 -c 'printf "%s\n" $a'
\/
would probably need to be covered [14] in the spec as well
(probably unspecified like for a='foo\')
--
Stephane
2019-06-18 10:24:20 -0400, Chet Ramey:
> On 6/18/19 6:47 AM, Stephane Chazelas wrote:
> > 2019-06-18 11:27:18 +0100, Stephane Chazelas:
> > [...]
> >> A [12] and [13] to add to the list (though it could just be a
> >> bug in bash):
> > [...]
>
2019-06-18 15:39:37 +, Michael Greenberg:
> What should the behavior of `printf %5%` be? Most shells I've tested
> seem to consider it an error; ksh prints out a plain percent sign
> without the four leading spaces.
>
> In my reading of the "File Format Notation" section of the base
> definiti
2019-06-19 23:40:05 +0700, Robert Elz:
[...]
> I believe that consistency is more important. Unquoted var expansions
> in sh have always been a "time bomb", and will continue to be.
Unless we specify zsh's globsubst option (and shwordsplit while
we're at it) and the $~var, $=var operators that c
2019-06-20 03:03:49 +0700, Robert Elz:
[...]
> | and that is highly likely to break existing shell scripts,
>
> And yet, apparently, it doesn't.That's not actually very surprising,
> as what is of concern here is an aspect of the shell which never worked
> in anything like a rational manner,
2019-06-20 03:03:49 +0700, Robert Elz:
[...]
> The current text (leaving aside the weird line about removing \'s in 2.13.1)
> makes things consistent - where quote removal is performed, \ is a quote
> character, and we all agree what happens in that case. Where quote removal
> is not performed, t
2019-06-20 07:57:01 +0100, Harald van Dijk:
[...]
> To be clear, I was specifically referring to Geoff Clare's interpretation
> that
>
> set -- 'back\slash'
> set -- $*
>
> should set $1 to 'backslash', not 'back\slash', regardless of the contents
> of the current directory.
>
> Is that real
2019-06-18 10:32:45 +0100, Geoff Clare:
[...]
> There's no need to be so melodramatic. You are overstating the
> consequences of shells changing to become conforming. They are
> really quite minor, and mostly only affect badly written shell
> scripts where the author forgot to quote something. T
2019-06-21 08:00:34 +0100, Stephane Chazelas:
[...]
> If you want some examples, the autoconf "configure" script as
> used for instance to build bash is affected by the change where
> it now has one of those "time-bomb" bugs you were referring to.
[...]
and remember
2019-06-20 16:02:02 -0400, Chet Ramey:
> On 6/18/19 1:37 PM, Austin Group Bug Tracker wrote:
>
> > Should output \., but since version 5, it outputs . instead. I'm starting
> > to suspect the change was not intentional (or at least that the
> > consequences of the change were overlooked) as despit
2019-06-21 23:28:30 +0700, Robert Elz:
[...]
> ps: Stephane - where this really matters is not in cases like
>
> files='*.txt'
> cmd -- $files
>
> but in cases like
>
> printf "List the files to use: "
> read files
> cmd -- $files
>
> where the user carefully tests
2019-06-20 09:03:38 +0700, Robert Elz:
> Date:Wed, 19 Jun 2019 22:10:43 +0100
> From: Stephane Chazelas
> Message-ID: <20190619211043.wnlhw2haih6ns...@chaz.gmail.com>
>
> | By that reasoning, we should also make sure that
> |
>
2019-06-21 09:05:09 +0100, Stephane Chazelas:
[...]
> That autoconf example above is actually pretty damning.
[...]
> as_echo='printf %s\n'
[...]
Another ironic thing with that example is that that autoconf
code is about working around the fact that the POSIX echo is not
2019-06-21 15:18:49 -0500, Eric Blake:
[...]
> The fact that bash 5's
> behavior breaks as_echo in the presence of certain filenames is
> definitely a discouraging regression; but I haven't paid enough
> attention to the details of this thread to know if it was broken only in
> the initial bash 5 r
2019-06-21 11:15:51 +0100, Geoff Clare:
[...]
> > if test -n "$BASH_VERSION"; then
> > eval 'as_f_echo() { printf "%s\n" "$@"; }'
> > as_echo=as_f_echo
> > fi
>
> Probably simpler just to put "set -f" at the top of the configure
> script. (And if globbing is needed at any point, turn it back
2019-06-21 23:58:32 +0100, Harald van Dijk:
[...]
> In theory, pathname expansion is supposed to be done for every word, no
> matter which characters it contains. Even in something as simple as
>
> echo hello
>
> both words undergo pathname expansion. The first word is supposed to be
> matched
2019-06-22 07:04:37 +0700, Robert Elz:
[...]
> | You just shot yourself in both feet there :-)
> |
> | 1- read without -r also handles \,
>
> So, rather than droning on about that error of mine, simply
> assume I used read -r instead.
Because you have realised \ was way too overloaded?
>
2019-06-22 09:07:40 +0100, Harald van Dijk:
[...]
> > > In theory, pathname expansion is supposed to be done for every word, no
> > > matter which characters it contains. Even in something as simple as
[...]
> > That's your way to look at it.
>
> That's the way it's specified in POSIX.
Note that
2019-06-22 13:57:44 +0100, Harald van Dijk:
[...]
> > But in bash5's
> >
> > files='/a/\b/??/x/*'
> > ls -d $files
> >
> > That \ becomes a globbing operator, so we get the same list of
> > files as in a literal /a/[b]/??/x/*, not a literal /a/\b/??/x/*
>
> That doesn't sound right. The backslas
2019-06-24 12:13:34 +0100, Geoff Clare:
> For this particular issue there is a strong case for upholding
> the requirements of the standard, for the sake of consistency.
[...]
I disagree. Here the inconsitency is caused by the way POSIX
chose to write the specification. They chose to specify the
b
2019-06-24 10:16:34 -0400, Chet Ramey:
[...]
> Bash-5.0 patch 3 made some changes here; what version are you using?
[...]
Just tried with the current head of the devel branch from today
(5.0.7(5)-maint).
In an empty dir:
$ mkdir -m a=r readable
$ mkdir -m a=x searchable
$ bash5 -c 'printf "%s\n
2019-06-24 09:48:21 -0400, Chet Ramey:
> On 6/22/19 2:51 AM, Stephane Chazelas wrote:
>
> > For them, and me, and it seems Eric as well, globbing is an
> > operator that is invoked whenever a word contains an unquoted
> > wildcard character (in "list" contexts)
2019-06-24 09:42:42 -0400, Chet Ramey:
> On 6/24/19 9:33 AM, Joerg Schilling wrote:
>
> >> Bash claims posix conformance with the posix and xpg_echo options enabled.
> >> You can build bash so that both of these are enabled for strict
> >> conformance.
> >
> > I know, but it would be nice if tha
2019-06-24 11:52:56 -0400, Chet Ramey:
[...]
> > Before going in the details of the language, can we at least
> > agree on what the "intention" should be?
>
> Your intention is obvious. It's in the part I quoted.
>
> Pathname expansion is performed on words that contain an unquoted
> `*', `?', or
2019-06-24 18:45:55 +0100, Harald van Dijk:
[...]
> FWIW, that is not what ksh implements and it might be an unreasonable
> requirement on ksh. From its manpage:
>
> > Following splitting, each field is scanned for the characters ∗, ?, (,
> > and [ unless the -f option has been set. [...]
>
> So
2019-06-24 18:45:55 +0100, Harald van Dijk:
[...]
> This particular example is already not required to behave in any particular
> way for other reasons, but I do not know whether changes to this example
> might produce something where an overly strict requirement in POSIX would
> prohibit ksh's beh
2019-06-24 21:56:48 +0100, Harald van Dijk:
> On 24/06/2019 21:15, Stephane Chazelas wrote:
> > But that means that those ksh extended glob operators are not
> > enabled in:
> >
> > pattern='@(x)'; cmd $pattern
> > or
> > case string in $patte
2019-06-25 08:51:38 +0100, Harald van Dijk:
[...]
> > IFS='|'
> > text='foo|bar'
> > for i in $text; do...
>
> All of these are fine, since it is about shell special characters during
> pattern matching. All the special characters in your examples are removed
> before pattern matching starts.
Wel
2019-06-26 12:24:21 +0100, Geoff Clare:
[...]
> On page 2383 line 76232 section 2.13.1 insert a new paragraph:
>
> Implementations may also treat as a special pattern a sequence of
> characters consisting of one of the following, unquoted and not
> inside a bracket expression:
>
>
2019-06-26 15:32:44 +0100, Geoff Clare:
[...]
> * the unquoted sequence "{n}" where n consists of one or more digits
>
> * the unquoted sequence "{m,n}" where m and n consist of zero or more
> digits
[...]
More like:
* the sequence "{n}" where n consists of one or more digits and
2019-06-26 15:32:44 +0100, Geoff Clare:
[...]
> Implementations may also treat as a special pattern a sequence of
> characters consisting of one of the following, not inside a bracket
> expression:
>
> * an unquoted '?' or '*' character
>
> * a (quoted or unquoted) '+', '@', '
2019-06-26 17:24:49 +0100, Stephane Chazelas:
> 2019-06-26 15:32:44 +0100, Geoff Clare:
[...]
> That could be interpreted as implying that a sequence that
> includes a ( followed by two unquoted ) is required *not* to be
> treated specially.
>
> Yet, @(@(x)) is still special
2019-06-26 23:56:06 +0100, Harald van Dijk:
[...]
> You are proposing a fundamental change to the design of pattern matching,
> not a clarification as you previously called it, and you are now discussing
> how to allow the behaviour of one specific shell that does not behave the
> way you like, but
2019-06-27 08:59:29 +0100, Harald van Dijk:
[...]
> > 2 is slightly more portable, but even in those shells where it
> > does that, that's not because they implement \ processing the
> > way POSIX seems to specify it, and all do it a different way.
> > I'm not opposing POSIX *allows* a \ in an unqu
2019-06-27 11:51:11 +0100, Geoff Clare:
> Joerg Schilling wrote, on 27 Jun 2019:
[...]
> > > 2.
> > >
> > > a='\**'
> > > printf '%s\n' $a
> > >
> > > is a portable script that is meant to list the filenames that
> > > start with "*" in the current directory
> >
> > See 1), there is just one shel
2019-06-27 12:27:55 +0200, Joerg Schilling:
[...]
> > 4 is portable in practice. 5 as well but only because of the
> > buggy fallback string comparison in ksh93.
>
> So you wrote this because the shell that makes @ special also
> has the fallback?
[...]
Well, it may be tempting to suspect that k
2019-06-27 14:04:18 +0200, Joerg Schilling:
[...]
> > And kresh (netbsd 8.1) and zsh in sh mode. In zshsh, that's
>
> I cannot check "kresh" as it does not compile on UNIX.
Note that you can install NetBSD in a VM in a few minutes. I
just did that a few days ago to test that shell's behaviour.
Yo
2019-06-27 10:55:12 -0400, Chet Ramey:
[...]
> > And that shell is "bash" (not just "bash5"). All versions I tried do
> > it (including bash3 on macOS).
>
> This behavior has been in the bash pattern matcher since the pre-1.0
> releases. The oldest version I have built is bash-2.05b, but the code
2019-06-21 18:48:16 +, Austin Group Bug Tracker:
[...]
> There's another aspect which I haven't mentioned yet (I'll develop more on
> that later) where the bash5 behaviour is making things worse when character
> sets like BIG5, GB18030 that have characters that contain the encoding of
> backsla
2019-06-27 10:48:20 -0400, Chet Ramey:
> On 6/27/19 2:15 AM, Stephane Chazelas wrote:
>
> > I could be convinced that it makes sense for the ksh93 X(...)
> > operators to be allowed if there was one non-anecdotal
> > implementation of fnmatch() that implemented it, but I
2019-07-03 09:24:10 +0100, Geoff Clare:
[...]
> [...] If any character (ordinary, shell
>special, or pattern special) is quoted or (where shell quoting is not
>in effect) escaped with a , that pattern shall match the
>character itself. [...]
[...]
And agai
2019-07-03 11:08:57 +0100, Geoff Clare:
[...]
> > And again, that's an incompatible change for dash, ksh88, ksh93,
> > pdksh, mksh, bosh, yash where:
> >
> > a='\*'
> > ls -ld $a
> >
> > lists the files that start with \
>
> Which is inconsistent with find, pax, fnmatch() and glob().
And again
2019-07-03 15:19:18 +0100, Geoff Clare:
[...]
> > Irrelevant, pax, fnmatch() and glob() don't do variable
> > expansion. find -name '$a' is unspecified but in all
> > implementations, that returns the files called $a literally.
>
> The goal is consistency of how backslash behaves in patterns.
> A
2019-07-04 09:26:50 +0100, Geoff Clare:
[...]
> > > a='*'
> > > ls -ld "$a"
> > >
> > > This does work for listing only a file literally named '*'.
> >
> > That's because of the double quotes around $a. Pathname expansion
> > is not done inside double quotes, so there is no pattern here, jus
2019-07-04 10:34:37 +0100, Stephane Chazelas:
[...]
> See 2.6.2 parameter expansion:
>
> } If a parameter expansion occurs inside double-quotes:
> }
> } • Pathname expansion shall not be performed on the results of the
> expansion.
> }
> } • Field splitting shall
2019-07-18 12:08:54 +, Austin Group Bug Tracker:
[...]
> If we add GLOB_NOCHECK as suggested to reduce the difference between using
> glob()+execvp() and executing "ls -ld -- *.c" in the shell, then we should
> add GLOB_ERR as well.
[...]
Why GLOB_ERR? The shell does silently ignore directory
Well, it gets more complicated if you bring job control to the
equation.
In:
{ cmd1; cmd2 | cmd3; }
Most shells (zsh being an exception) start a job for cmd1 and
one for cmd2|cmd3, IOW for each pipeline (but in effect, only
the pipeline of the $$, not of subshells).
zsh tries to address it by f
2019-07-23 09:55:52 +0100, Geoff Clare:
[...]
> > Why GLOB_ERR? The shell does silently ignore directory open and
> > read errors when expanding globs. In
> >
> >ls -ld -- *.c
> >
> > The shell would run ls with a literal *.c as argument without
> > giving any warning when the current directo
2019-07-23 12:29:29 +0100, Geoff Clare:
[...]
> > > The shell should ignore EACCES errors from opendir() (and probably
> > > ELOOP, ENAMETOOLONG, ENOENT and ENOTDIR, none of which apply for "*.c")
> > > but if opendir() fails with EMFILE or ENFILE the shell should report
> > > an error.
> > [...]
>
2019-07-23 14:12:22 +0200, Joerg Schilling:
> Geoff Clare wrote:
>
> > If any shell does not report an error when opendir() returns EMFILE
> > or ENFILE then that's definitely a bug in that shell. Silently
> > executing a command with the unchanged pattern instead of with the
> > pathnames that
1 - 100 of 416 matches
Mail list logo
