On 30/09/2018 00:18, Robert Elz wrote:
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
error
message for
LC_ALL=C
: $'\u1234'
as zsh does, does this allow and/or require that same error message to
be produced for
LC_ALL=C
: || : $'\u1234'
Cheers,
Harald van Dijk
On 31/12/2018 10:18, Stephane Chazelas wrote:
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
On 01/01/2019 20:45, Chet Ramey wrote:
On 12/28/18 2:57 PM, Harald van Dijk wrote:
I gave the example of
alias mycase=case
mycase x in (x) echo ok ;; esac
I do not see how this is supposed to work under the new wording. However,
looking in more detail, I do not see how this is supposed
On 02/01/2019 00:21, Chet Ramey wrote:
On 1/1/19 5:10 PM, Harald van Dijk wrote:
Alias expansion happens "before applying the grammatical rules", so there's
no lookahead. `mycase' is just a word that is subject to alias expansion.
But once you know you have a WORD token and
Dijk
On Tuesday, January 1, 2019 Harald van Dijk wrote:
On 02/01/2019 00:21, Chet Ramey wrote:
> Even if you
> restrict a function name to be a NAME it's still subject to alias
> expansion.
I may be misunderstanding you again here, but if the function name is
neither a word
On 02/01/2019 02:34, Chet Ramey wrote:
On 1/1/19 8:33 PM, Harald van Dijk wrote:
Ah! Now I think I see how we are interpreting things differently. Am I
understanding correctly that given
echo hello (
you are saying that this will (conceptually) successfully parse a simple
command
On 02/01/2019 13:28, Chet Ramey wrote:
On 1/1/19 10:15 PM, Harald van Dijk wrote:
On 02/01/2019 02:34, Chet Ramey wrote:
On 1/1/19 8:33 PM, Harald van Dijk wrote:
Ah! Now I think I see how we are interpreting things differently. Am I
understanding correctly that given
echo hello (
you
On 02/01/2019 19:13, Chet Ramey wrote:
On 1/2/19 1:44 PM, Harald van Dijk wrote:
That's not how I read it. Alias expansion is performed "after a token has
been delimited, but before applying the grammatical rules." I take that to
mean that the token hasn't been determined to be a WO
On 02/01/2019 13:32, Robert Elz wrote:
Date:Wed, 2 Jan 2019 03:15:10 +
From:Harald van Dijk
Message-ID:
| But actually... I now wonder if "command name word of a simple command"
| might refer simply to the "cmd_name : WORD" produ
On 04/01/2019 21:24, Robert Elz wrote:
Date:Fri, 4 Jan 2019 18:44:20 +
From:Harald van Dijk
Message-ID:
| If the intent is to make all the non-trivial cases unspecified, while
| still allowing the previously required behaviour, then aliases ending
On 15/01/2019 11:15, Joerg Schilling wrote:
Harald van Dijk wrote:
Can there be an alternative rewording that specifies the behaviour in
even more cases, where the resulting text is still both correct and
understandable, and the extra cases are verified to work the same way on
all current
On 15/01/2019 11:03, Joerg Schilling wrote:
Harald van Dijk wrote:
On 14/01/2019 13:32, Joerg Schilling wrote:
posh does not work on platforms with a POSIX compliant getopt(), so there are
other reasons not to take posh into account.
This is misleading. There are platforms with a POSIX
platforms with a POSIX
compliant getopt() on which it does work. Almost all shells, if not all,
rely on extensions and/or make some not-100%-portable assumptions. That
is not a good reason to disregard them.
Cheers,
Harald van Dijk
lt you are after
(which I would like to see myself as well, even though I do not feel as
strongly about it as you).
Cheers,
Harald van Dijk
On 15/01/2019 23:04, Robert Elz wrote:
Date:Tue, 15 Jan 2019 20:38:15 +
From:Harald van Dijk
Message-ID:
| On 15/01/2019 15:13, Joerg Schilling wrote:
| > would make it she slowest shell in the universe.
| parser as well. Testing on its
ome up with something resembling
alias forever='while :; do'
Is the intent really to invalidate such uses? If so, is the intent to
require shells to issue errors for this, or will shells somehow be
allowed to continue implementing it the way it is currently required?
Cheers,
Harald van Dijk
the desired effect.
Cheers,
Harald van Dijk
est of the comment still makes perfect sense if
you take out the ", unlike the contents of a dot script" bit, I think.
Cheers,
Harald van Dijk
for any character is prescribed; thus the
common Japanese practice of using the glyph “¥” for the C character “\” is
perfectly legitimate.)
This reasoning seems like it would apply to POSIX equally well.
Cheers,
Harald van Dijk
command without any control operator to terminate it.
The standard itself shows the eval command used that way in its
description of that.
It already follows from the grammar that *if* a control operator is
seen, it cannot be taken as part of the simple command.
Cheers,
Harald van Dijk
On 04/01/2019 01:13, Robert Elz wrote:
Date:Fri, 4 Jan 2019 00:08:58 +
From:Harald van Dijk
Message-ID: <33439700-ff2c-ae03-ab9c-ee9b43b85...@gigawatt.nl>
| Allowing arbitrary function names is not something other shells
| genera
g tokenising, then no problem, they would
already be unspecified implicitly. If it's later, then they should be
made explicitly unspecified if they occur in an alias.
Cheers,
Harald van Dijk
On 28/12/2018 11:08, Joerg Schilling wrote:
Harald van Dijk wrote:
Hi,
Reading <http://austingroupbugs.net/view.php?id=1055#c3292>, I'm very
surprised to discover that how aliases work is being completely
rewritten in a way incompatible with existing shells and existing shell
s
which is able to handle this.
Cheers,
Harald van Dijk
On 03/01/2019 00:18, Robert Elz wrote:
Date:Wed, 2 Jan 2019 21:52:59 +
From:Harald van Dijk
Message-ID: <9dcb933f-8dd5-62b5-e420-bfbf7fbda...@gigawatt.nl>
| You've left out the part of my message that you replied to that two
| shells *do* do it
at also fail
for other reasons and require major changes to their implementations of
aliases to solve.
Cheers,
Harald van Dijk
On 27/01/2019 21:17, Stephane Chazelas wrote:
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
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: end of file unexpected
Cheers,
Harald van Dijk
-derived shells... :) That's how I could be sure enough to say it is
easy to fix.
Cheers,
Harald van Dijk
On 01/02/2019 02:55, Robert Elz wrote:
Date:Thu, 31 Jan 2019 22:04:30 +
From:Harald van Dijk
Message-ID: <126fa44f-05bb-abc2-d6c9-40b82b36f...@gigawatt.nl>
|alias foo=bar
|echo foo
|
| alias substitution should not be performed o
be parsed as the command name word of a simple
command (see [xref to Section 2.10]), based on this TOKEN and
the tokens (if any) that preceded it, but ignoring whether any
subsequent characters would allow that
Good point, that looks better.
Cheers,
Harald van Dijk
On 01/02/2019 09:56, Robert Elz wrote:
Date:Fri, 1 Feb 2019 08:00:16 +
From:Harald van Dijk
Message-ID: <5cd22a9c-b213-8ffb-da45-f71057eba...@gigawatt.nl>
| I was referring to the second token on the second line, which is foo,
| not foo=bar.
Oh,
On 03/06/2019 10:54, Joerg Schilling wrote:
Harald van Dijk wrote:
(Re-sending from the right e-mail address, apologies if it arrives twice.)
On 30/05/2019 20:44, Nick Stoughton wrote:
During today's teleconference we discussed whether the pathname
expansion ".*" should alwa
On 04/06/2019 15:52, Joerg Schilling wrote:
Harald van Dijk wrote:
Currently, two incompatible behaviours are implemented in shells:
(1) Let the result depend on readdir().
(2) Always omit "." and "..".
With the "globskipdot" option, shells that currently impl
e, it is
simpler for a script author to write . .. .* than it is to turn off
globskipdot, write .*, and turn globskipdot back on again.
The bug's desired action, allowing the behaviour of aforementioned
shells and considering making it a requirement in the future, looks like
a much better idea to me.
Cheers,
Harald van Dijk
On 03/06/2019 13:02, Joerg Schilling wrote:
Harald van Dijk wrote:
echo .*/Makefile
which is:
../Makefile ./Makefile
False. Assuming those paths exist and no other paths match, the
currently expected result depends. It can either be what you wrote, or
it can
On 01/06/2019 07:25, Stephane Chazelas wrote:
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
basename is an absolute path
(which as mentioned is questionable), this is doable with just POSIX sh:
${dirname%/}/${basename#"${basename%%[!/]*}"}
Cheers,
Harald van Dijk
On 10/06/2019 20:25, Chet Ramey wrote:
On 6/10/19 3:15 PM, Harald van Dijk wrote:
On 10/06/2019 19:22, Chet Ramey wrote:
On 6/10/19 2:15 PM, Harald van Dijk wrote:
Re: http://austingroupbugs.net/view.php?id=760#c4411 <&0 is a no-op, so
it's
unclear whether it counts as
"explicit
On 11/06/2019 09:39, Geoff Clare wrote:
Harald van Dijk wrote, on 10 Jun 2019:
On 10/06/2019 09:46, Austin Group Bug Tracker wrote:
--
(0004413) geoffclare (manager) - 2019-06-10 08:46
http://austingroupbugs.net/view.php
On 18/06/2019 10:51, Geoff Clare wrote:
Harald van Dijk wrote, on 17 Jun 2019:
In 2.13.1, "This escaping " refers to the escaping
defined in the previous sentence. The full previous sentence is conditional:
"When pattern matching is used where shell quote removal i
On 22/06/2019 13:40, Stephane Chazelas wrote:
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
sh' is a supported command and execute it if so. That is enough to get
zsh to enter POSIX mode and accept 'set -f' with the standard meaning.
Cheers,
Harald van Dijk
On 24/06/2019 15:16, Chet Ramey wrote:
On 6/22/19 8:57 AM, Harald van Dijk wrote:
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
nsion when coming up with new wording for POSIX.
Cheers,
Harald van Dijk
On 24/06/2019 11:04, Joerg Schilling wrote:
Austin Group Bug Tracker wrote:
Where you refer to "*every* shell (except bash5 ...)", that's inaccurate
because:
1. Robert Elz and Harald van Dijk have shells that behave like bash5.
I would be happy to check these shells, but unf
On 25/06/2019 08:30, Stephane Chazelas wrote:
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 $pattern) ...
(for the latter
On 19/06/2019 09:43, Geoff Clare wrote:
Harald van Dijk wrote, on 18 Jun 2019:
It seems to me that 2.13.1 should be interpreted as overriding 2.13.3,
as otherwise there would be no point in having that statement there.
It is what clarifies or specifies that `find . -name '\*'` looks
On 19/06/2019 21:03, Robert Elz wrote:
Date:Wed, 19 Jun 2019 18:30:36 +0100
From:Harald van Dijk
Message-ID:
| If your conclusion is that the intent of the standard is to specify
| something that no shell does
That may have been true at the time the text
On 20/06/2019 09:42, Stephane Chazelas wrote:
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
no scan of the current directory would be needed,
as results would be identical regardless of the contents. That is also
an advantage many shells' behaviour of treating unquoted backslash as a
literal character have. But if backslash does also function as an escape
character during pattern matching, it needs to trigger globbing as well.
Cheers,
Harald van Dijk
On 22/06/2019 07:51, Stephane Chazelas wrote:
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
On 22/06/2019 01:46, Robert Elz wrote:
Date:Fri, 21 Jun 2019 23:58:32 +0100
From:Harald van Dijk
Message-ID: <49108c83-bd68-a329-25c5-118b0f911...@gigawatt.nl>
| Obviously, this means that pathname expansion produces "echo",
| regardless
a
echo ~(N)a ~(N)b
This is supposed to produce 'a'.
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 behaviour.
s the required behaviour
and it is a (minor) bug for a few shells to implement it as a no-op.
Cheers,
Harald van Dijk
, it is not clear to me what the intent is.
Cheers,
Harald van Dijk
On 03/07/2019 09:24, Geoff Clare wrote:
Harald van Dijk wrote, on 02 Jul 2019:
That's not because the word "unquoted" is used, which only applies to shell
quoting, that's because 2.13.1 contains "All of the requirements and effects
of quoting on ordinary, shell special, and
On 04/07/2019 09:09, Geoff Clare wrote:
Harald van Dijk wrote, on 03 Jul 2019:
No, it's a context where shell-quoting backslash *doesn't* work. Therefore
the backslash should act as an escape character just like in find, pax,
fnmatch() and glob().
It's not about shell quoting the backslash
sponded then:
POSIX intends to create portability at source code level.
Code that is not portable does not follow the POSIX way.
That's not a requirement for POSIX implementations, so it's not relevant.
Cheers,
Harald van Dijk
e should move in that direction. See http://www2.research.att.com/sw/download/man/man1/ksh.html [^] for man page details. New wording invited.
Cheers,
Harald van Dijk
On 03/07/2019 15:27, Geoff Clare wrote:
Harald van Dijk wrote, on 03 Jul 2019:
On 03/07/2019 11:08, Geoff Clare wrote:
Stephane Chazelas wrote, on 03 Jul 2019:
2019-07-03 09:24:10 +0100, Geoff Clare:
[...]
[...] If any character (ordinary, shell
special
On 02/07/2019 10:20, Geoff Clare wrote:
Harald van Dijk wrote, on 01 Jul 2019:
On 01/07/2019 10:36, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Jun 2019:
POSIX does not even limit the concept of "syntax errors" to errors in the
syntax, see e.g. the "shift" command
On 28/06/2019 09:38, Geoff Clare wrote:
Harald van Dijk wrote, on 27 Jun 2019:
On 27/06/2019 10:04, Geoff Clare wrote:
Stephane Chazelas wrote, on 26 Jun 2019:
Or again, forget all about it and treat the ksh93 behaviour as
non-compliant as is already the case.
I'm starting to think
On 28/06/2019 16:05, Joerg Schilling wrote:
Harald van Dijk wrote:
That aside, I asked you last time you made this claim about POSIX to
back it up. There is no requirement for standard utilities to be
implemented portably. You responded then:
POSIX intends to create portability at source
ld.
Cheers,
Harald van Dijk
On 01/07/2019 10:36, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Jun 2019:
On 28/06/2019 09:38, Geoff Clare wrote:
Harald van Dijk wrote, on 27 Jun 2019:
On 27/06/2019 10:04, Geoff Clare wrote:
In particular, XRAT's explanation of it is "Conforming applications
are required to
y required to match
single characters in the text being matched, that is doable.
Cheers,
Harald van Dijk
ts special
meaning in bracket expressions, but shell quoting allows arbitrary
characters to appear. What should the shell do when fed [[=".=]"=]]? How
is this implementable?
Cheers,
Harald van Dijk
the
characters in '[:alpha', followed by ':]]', is something I only see in
osh and in your shell.
Cheers,
Harald van Dijk
On 26/09/2019 14:27, Joerg Schilling wrote:
Harald van Dijk wrote:
Not the same way, but it could still be trivially fixed: instead of
as_echo='printf %s\n'
configure scripts could do
as_echo() { printf '%s\n' "$@"; }
as_echo=as_echo
Well, the problem with us
rement on applications, is it not? When
that requirement is violated, the regular expression or shell pattern is
undefined, and interpreting alpha] as an invalid character class name is
a reasonable result.
Cheers,
Harald van Dijk
On 27/09/2019 02:26, Robert Elz wrote:
Date:Thu, 26 Sep 2019 22:58:10 +0100
From:Harald van Dijk
Message-ID:
| 9.3.5 rule 1:
| "shall be followed by" is a requirement on applications, is it not?
It is.
| When that requirement i
ression when used in other contexts, therefore this
would be required to expand to "[/\.]" regardless of the contents of the
file system. Is that understanding correct?
Cheers,
Harald van Dijk
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.
In zsh, backslash is given this special treatment only if the next
character is special, so an indirect [a]\? matches a?, but an indirect
[a]\b does not match ab.
Cheers,
Harald van Dijk
On 24/09/2019 12:24, Geoff Clare wrote:
Harald van Dijk wrote, on 24 Sep 2019:
2. Existing practice in most shells that do treat backslash as special in
"indirect" patterns in pathname expansions is only to match patterns
against existing pathnames if the patter
On 24/09/2019 15:32, Geoff Clare wrote:
Harald van Dijk wrote, on 24 Sep 2019:
There is a reason I wrote "in its current version". I do not think it is
reasonable to describe bash 4 behaviour that had already been changed when
this was being discussed as "existing practice"
On 26/09/2019 01:47, Robert Elz wrote:
Date:Wed, 25 Sep 2019 22:29:36 +0100
From:Harald van Dijk
Message-ID:
| These all seem reasonable choices. regcomp() would reject the whole
| pattern as an error, and character classes are supposed to behave
On 26/09/2019 02:36, Harald van Dijk wrote:
POSIX mentions the possibility of locale-specific character classes and
they are required to be recognised in regular expressions and therefore
in shell glob patterns:
In addition, character class expressions of the form:
[:name:]
are recognized
YPE, but
by stating that the minimum set of error return values includes
REG_ECTYPE, the standard requires regcomp() to return REG_ECTYPE for at
least some patterns.
Cheers,
Harald van Dijk
On 30/09/2019 12:00, Geoff Clare wrote:
Harald van Dijk wrote, on 30 Sep 2019:
(As an aside, why is this exception limited to patterns used for filename
expansion? Existing practice is that it applies to all patterns:
case [a in [*) echo match ;; *) echo no match ;; esac
This prints
On 30/09/2019 10:51, Geoff Clare wrote:
Harald van Dijk wrote, on 28 Sep 2019:
On 23/09/2019 16:39, Austin Group Bug Tracker wrote:
--
(0004564) geoffclare (manager) - 2019-09-23 15:39
http://austingroupbugs.net/view.php
On 27/06/2019 07:15, Stephane Chazelas wrote:
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
On 13/12/2019 00:44, Robert Elz wrote:
Date:Thu, 12 Dec 2019 21:37:55 +
From:Harald van Dijk
Message-ID:
| This change would benefit not just those shells, but also other existing
| shells,
The point of the standard isn't to benefit the shells
On 14/12/2019 11:29, Robert Elz wrote:
Date:Fri, 13 Dec 2019 08:57:28 +
From:Harald van Dijk
Message-ID: <9c1e4a98-e557-e5d1-27bc-05e7bbfe5...@gigawatt.nl>
| Pretending such scripts are portable does a disservice to users.
Since the shells yo
in unclosed bracket expressions, by
not requiring re-parsing from the unmatched '['.
Cheers,
Harald van Dijk
On 15/12/2019 12:38, Robert Elz wrote:
Date:Sat, 14 Dec 2019 14:41:34 +
From:Harald van Dijk
Message-ID: <9cbcf0fd-83d1-b449-cfe8-eafdee14b...@gigawatt.nl>
| This was not an exhaustive list, nor was it intended to be.
Still, if one relies (at all
named 'a'.
Is my understanding correct? If so, should these patterns become
unspecified as well, to allow current and older shell behaviour?
Cheers,
Harald van Dijk
ands to be forgotten, including
those found through function definitions.
Cheers,
Harald van Dijk
On 27/10/2019 17:16, Robert Elz wrote:
Date:Sun, 27 Oct 2019 15:44:52 +
From:Harald van Dijk
Message-ID: <01735f8e-c0ef-a1d6-f8d1-258a669d9...@gigawatt.nl>
| This could potentially be useful if the script author knows the command
| will be ex
,
Harald van Dijk
On 24/10/2019 08:16, Robert Elz wrote:
Date:Thu, 24 Oct 2019 06:46:52 +0100
From:Harald van Dijk
Message-ID: <5d23eeba-1ac5-6574-d348-2a8b43f97...@gigawatt.nl>
| This is currently well-defined. We are talking about changing the
| standard t
On 24/10/2019 00:42, Robert Elz wrote:
Date:Wed, 23 Oct 2019 20:58:08 +0100
From:Harald van Dijk
Message-ID:
| That is, if a user runs
|echo "/dev/"*
| dash will call glob() with a pattern string of '\/dev\/*'.
Bizarre. Why?
fore slash in glob() is probably a
step too far.
Cheers,
Harald van Dijk
ut unless POSIX adds these options, determining how
they should interact with indirect backslashes should probably not be
done on this list.
Cheers,
Harald van Dijk
On 25/09/2019 10:22, Geoff Clare wrote:
Harald van Dijk wrote, on 24 Sep 2019:
Regardless, a single shell is not enough to say "most shells", not even if
it is multiple versions of that single shell.
I consider bash 4 on Linux and bash 3 on macOS to be different shells.
(T
attern [[="x="]] should change
to "one of [=x=, followed by ]", just like how the pattern [["=x="]] is
treated already. Does that sound right?
Cheers,
Harald van Dijk
On 25/09/2019 22:49, Stephane Chazelas wrote:
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
https://www.mail
normal, including alias substitution. However,
as parsing $(switch foo in foo) by itself results in a syntax error as
far as POSIX is concerned, shells are permitted to parse the full $(
switch foo in foo) echo ok;; esac ) as a command substitution as an
extension instead. All the results you see in shells appear to me to be
permitted by the standard.
Cheers,
Harald van Dijk
On 19/04/2020 14:32, Koichi Murase wrote:
2020-04-19 21:55 Harald van Dijk :
My reading was that interpretation B must be what is intended, which
is why I had modified my shell, a fork of dash, to change dash's A
behaviour to B in late 2018.
Thank you. Is your shell this https://github.com
1 - 100 of 191 matches
Mail list logo
