On 11/16/20 4:45 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Jilles Tjoelker wrote, on 13 Nov 2020:
On Mon, Nov 09, 2020 at 03:07:43PM +, Geoff Clare via austin-group-l
at The Open Group wrote:
The ksh and bash behaviour of reporting multiple values seems more
useful to
On 11/19/20 5:05 AM, Geoff Clare via austin-group-l at The Open Group wrote:
2. If the last resource-specifying option has no option-argument,
treat the operand as if it was an option-argument for that option;
otherwise report a usage error (or ignore the operand).
This option sounds like
On 11/17/20 4:53 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 16 Nov 2020:
On 11/16/20 11:05 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 16 Nov 2020:
Thanks. Looks like bash is parsing the ulimit options
On 11/17/20 10:56 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 17 Nov 2020:
On 11/17/20 10:14 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Maybe you could handle those by seeing that the option argument is
alphabetic (and not "unli
On 11/17/20 10:14 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Maybe you could handle those by seeing that the option argument is
alphabetic (and not "unlimited") and treating it as a string of
option letters instead of reporting that it is an invalid number.
From `getopt's
On 11/16/20 11:05 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 16 Nov 2020:
Thanks. Looks like bash is parsing the ulimit options in an unusual
way instead of using getopt() or similar.
Quite the opposite. The bash ulimit builtin uses the same
On 1/9/21 4:34 PM, Martijn Dekker via austin-group-l at The Open Group wrote:
I would question that the currently published standard allows any regular
builtin to override the regular shell grammar with special syntactic
properties. What exactly do you base this on?
I imagine it's because
On 6/30/21 11:49 AM, Joerg Schilling via austin-group-l at The Open Group
wrote:
Erm, yes. For some reason, I assumed the OP wrote &> instead of >&
which have the same meaning in GNU bash (but &> is the parse-trouble
one even if the bash manpage actively recommends it). I guess their
?~>&?
On 6/29/21 5:09 PM, tg...@mirbsd.org via austin-group-l at The Open Group
wrote:
I know the GNU bash extension >& (which incidentally
violates POSIX on the parse level) but not ~>&…
It doesn't. It's been unspecified for over 30 years.
--
``The lyf so short, the craft so long to lerne.'' -
On 4/15/21 4:36 PM, Martijn Dekker via austin-group-l at The Open Group wrote:
Most shells 'exec' the last command in -c scripts, e.g.:
However, no shell seems to do this for scripts loaded from a file:
My question: why is this? I would have thought that a script is a script
and that
On 4/11/21 4:17 PM, shwaresyst via austin-group-l at The Open Group wrote:
conforming applications can not rely on unspecified behaviors, so having a
use beyond that specified makes the shell nonconforming. Calling it out
like that simply acknowledges a lot of shell implementations choose to
On 4/12/21 12:05 PM, Robert Elz via austin-group-l at The Open Group wrote:
Anything that the system can run, no matter how it does that, is acceptable.
If a system noticed a VAX format a.out, it could load a vax simulator, and
run the binary that way, without the user even noticing. If it
On 4/13/21 5:16 AM, Harald van Dijk via austin-group-l at The Open Group wrote:
Please note again that POSIX's Command Search and Execution doesn't say
"continue until execve() doesn't fail". It says "Otherwise, the command
shall be searched for using the PATH environment variable as described
On 4/16/21 3:41 PM, Philip Guenther via austin-group-l at The Open Group wrote:
-
7. An additional conversion specifier character, b, shall be supported as
follows.
...
The interpretation of a followed by any other sequence of
characters is
unspecified.
-
That exception is about
On 2/19/21 11:21 AM, Geoff Clare via austin-group-l at The Open Group wrote:
There is no way to apply rule 4 to produce "a token identifier acceptable at
that point in the grammar". The only token identifier acceptable at that
point in the grammar is WORD, and rule 4 does not produce WORD. Rule
On 2/19/21 11:22 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Yes, rule 4 is applied there, but your mistake is in assuming that
the *result* of rule 4 is that the token is converted to an Esac.
How is it not? "the [sic] TOKEN is exactly the reserved word esac" at this
point.
On 2/19/21 10:52 AM, Donn Terry via austin-group-l at The Open Group wrote:
It was oh so many years ago that I originally wrote that hideously awful
grammar to try to reflect what the ksh did, which was very much ad-hoc
parsing. I won't apologise for the ksh language the grammar tries to
On 2/19/21 10:33 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Observe that rule 4 is applied for the first word in a pattern even if that
pattern follows an opening parenthesis. Because of that, in my example, the
esac in parentheses is interpreted as the esac keyword token, not
On 2/19/21 12:56 PM, Robert Elz via austin-group-l at The Open Group wrote:
bash's behaviour is a little weird:
Nope, it's consistent with the standard.
bash5 $case esac in
(esac) echo match
-bash: syntax error near unexpected token `esac'
bash5 $esac
-bash: syntax error near
On 2/19/21 3:32 PM, Robert Elz wrote:
Date:Fri, 19 Feb 2021 14:30:25 -0500
From:Chet Ramey
Message-ID: <2b32112c-de72-c713-3f87-6840828c3...@case.edu>
| Nope, it's consistent with the standard.
I can understand that argument.
| that's not a fair reading
On 9/1/21 2:23 PM, Robert Elz via austin-group-l at The Open Group wrote:
> Date:Wed, 1 Sep 2021 19:04:12 +0100
> From:Harald van Dijk
> Message-ID: <837d3b5b-ac61-98eb-2741-d667a78e2...@gigawatt.nl>
>
> | Is there any statement that overrides the general
On 9/1/21 4:59 PM, (Joerg Schilling) wrote:
"Chet Ramey via austin-group-l at The Open Group"
wrote:
Given the following:
(exit 42)
a=$? b=`false` b=$?
echo $? $a $b
Bash prints 1 42 1.
The original (v7) bourne shell and the rest of the research line through v9
prints 1 1
On 12/17/21 5:11 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Currently POSIX does not require unset macros to expand to an empty
string. The standard is silent on the matter, so the behaviour is
implicitly unspecified.
It seems like this is an opportunity to standardize
On 12/17/21 5:11 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The more I think about it, the more I am convinced that an error
is the right thing for make to do,
The world is an imperfect place. It seems that few, if any, make
implementations agree. We can't start
On 12/16/21 5:27 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> Chet Ramey wrote, on 14 Dec 2021:
>>
>> On 12/14/21 5:15 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>>> Paul Smith wrote, on 13 Dec 2021:
>>>> Why shouldn't we just
On 12/14/21 5:15 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> Paul Smith wrote, on 13 Dec 2021:
>> Why shouldn't we just state that
>> make implementations must expand unset variables to the empty string,
>> which is what all implementations (that I'm aware of) do anyway?
>
> The
On 1/27/22 10:18 AM, Harald van Dijk via austin-group-l at The Open Group
wrote:
On 27/01/2022 12:44, Geoff Clare via austin-group-l at The Open Group wrote:
Christoph Anton Mitterer wrote, on 26 Jan 2022:
3) Does POSIX define anywhere which values a shell variable is required
to be able
On 1/27/22 12:25 PM, Chet Ramey wrote:
On 1/27/22 12:07 PM, Harald van Dijk via austin-group-l at The Open Group
wrote:
On 27/01/2022 16:06, Chet Ramey via austin-group-l at The Open Group wrote:
Wow, that seems like a bug. Environment variables can contain sequences of
arbitrary non-NULL
On 1/27/22 12:07 PM, Harald van Dijk via austin-group-l at The Open Group
wrote:
On 27/01/2022 16:06, Chet Ramey via austin-group-l at The Open Group wrote:
Wow, that seems like a bug. Environment variables can contain sequences of
arbitrary non-NULL bytes, and, as long as the portion before
On 2/6/22 1:23 PM, Robert Elz via austin-group-l at The Open Group wrote:
They are definitely allowed, what saves all of us is that no-one
ever writes this, and if anyone ever attempted it, they'd probably be
hoping that the end-word on the here-doc redirect would be expanded
the same way it is
On 2/6/22 6:14 AM, Thorsten Glaser via austin-group-l at The Open Group wrote:
Robert Elz via austin-group-l at The Open Group dixit:
But there is a somewhat weird case that the shells (those for which
this works at all, which is a minority) differ about, that I don't
Which is correct, and
On 9/4/23 3:58 AM, Geoff Clare via austin-group-l at The Open Group wrote:
| Issue 9 will have an inconsistency between the printf() function and the
| printf utility.
Yes. And exactly why is that a problem?
I think everyone in the teleconference just assumed that the inconsistency
On 9/3/23 4:22 PM, Robert Elz via austin-group-l at The Open Group wrote:
Date:Sun, 3 Sep 2023 07:36:59 +0100
From:Stephane Chazelas
Message-ID: <20230903063659.mzyfen4evyrnz...@chazelas.org>
| though has the same limitation as my bash echo -e "$*\n\c"
Yes,
On 8/31/23 11:35 AM, Eric Blake wrote:
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 printf(3) (to produce 0b000... binary
On 9/3/23 2:36 AM, Stephane Chazelas via austin-group-l at The Open Group
wrote:
And except with yash's printf (among the few printf's I've
tested):
$ LC_ALL=zh_TW luit
$ locale title charmap
Chinese locale for Taiwan R.O.C.
BIG5
$ echo() { printf '%b ' "$@"\\n\\c; }
$ echo 'α'
αn%
(the
On 5/11/22 6:56 PM, Robert Elz wrote:
| Maybe. And yet I can't recall ever receiving a bug about this.
[...]
The circumstances to provoke a problem need to be contrived.
Exactly. It's a largely hypothetical scenario.
--
``The lyf so short, the craft so long to lerne.'' -
On 5/12/22 10:03 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The normative text relating to creation of job numbers/IDs is all
conditional on job control being enabled.
Where is that? It's not in the definition of Job ID, it's not in 2.9.3
Asynchronous Lists, it's not in the
On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
[Robert intended to send the mail I'm replying to to the list, but it
was only sent to me. I've quoted it in full.]
Robert Elz wrote, on 05 May 2022:
This leaves just bash of the shells I have to test. bash is odd,
On 5/11/22 6:31 PM, Robert Elz wrote:
| For neither the first nor the last time.
Including now.
People can disagree.
| > I think they should remain independent.
| Sure, I agree.
I don't. I cannot think of a single reason why the shell should be
forced to maintain two separate
On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
You are over reaching in the way you are reading that text.
I strongly disagree.
If you have to work that hard to make your case, it's a good indication
that the existing language is wrong -- or at least
On 5/13/22 10:27 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 13 May 2022:
On 5/13/22 5:20 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The definition of "Job" is:
A set of processes, comprising a shell pipeline, and any
On 5/18/22 9:46 PM, Christoph Anton Mitterer via austin-group-l at The Open
Group wrote:
The above, I'm not quite sure what these tell/prove...
I assume the ones with '?': that for all except bash/fnmatch '?'
matches both, valid characters and a single byte that is no character.
And the
On 5/13/22 5:37 PM, Robert Elz wrote:
Date:Sat, 14 May 2022 03:56:32 +0700
From:"Robert Elz via austin-group-l at The Open Group"
Message-ID: <2459.1652475...@jinx.noi.kre.to>
| | Show your work.
| I no longer remember the exact command I used (cannot
On 5/13/22 4:56 PM, Robert Elz wrote:
Date:Fri, 13 May 2022 11:22:20 -0400
From:Chet Ramey
Message-ID:
| Show your work.
|
| I tested this on macOS 12 and RHEL 7, using interactive shells with job
| control enabled,
That is likely the difference.
On 4/16/22 2:58 PM, Rob Landley via austin-group-l at The Open Group wrote:
Q) "How do I switch from FILE * to fd via fileno() without losing data."
A) "Don't use FILE *"
That's not the question I asked?
The answer is correct, but incomplete. The missing piece is that if you
want to use FILE
On 4/18/22 12:53 AM, Rob Landley wrote:
On 4/17/22 18:10, Chet Ramey wrote:
On 4/16/22 2:58 PM, Rob Landley via austin-group-l at The Open Group wrote:
Q) "How do I switch from FILE * to fd via fileno() without losing data."
A) "Don't use FILE *"
That's not the question I asked?
The answer
On 4/29/22 2:38 PM, Robert Elz via austin-group-l at The Open Group wrote:
| However, today it threw a last curve ball when I was working on an
| update to the description of set -b ...
How many shells actually implement that?
Bash does. I doubt anyone uses it.
| This conflicts
On 5/3/22 6:52 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Robert Elz wrote, on 30 Apr 2022:
| However, today it threw a last curve ball when I was working on an
| update to the description of set -b ...
How many shells actually implement that?
They all accept it as an
On 4/29/22 10:39 AM, Geoff Clare via austin-group-l at The Open Group wrote:
I'm responding to these messages in order; sorry if I cover ground that's
already been covered.
I've been gradually making progress on bug 1254 as a background task.
However, today it threw a last curve ball when I
On 4/29/22 4:23 PM, Robert Elz via austin-group-l at The Open Group wrote:
| You can test this by doing
|
|true &
|
|wait $!; echo $?
|
| This should print 0. Then do the same, except with the first command
| changed to false &. That should print 1.
Yes, in
On 5/5/22 7:46 AM, Geoff Clare via austin-group-l at The Open Group wrote:
The fact that the jobs command works with job control disabled is
mentioned in the rationale on the jobs page:
The jobs utility is not dependent on the job control option, as
are the seemingly related bg and
On 5/10/22 11:17 AM, Geoff Clare via austin-group-l at The Open Group wrote:
>> Anyway, I agree with disallowing remove-before-prompting.
>
> Unfortunately that puts you in opposition to kre.
For neither the first nor the last time.
>> Or make it clear everywhere that removing a job from the
On 5/10/22 12:03 PM, Geoff Clare via austin-group-l at The Open Group wrote:
>> If jobs and kill work, you should probably add wait to this description, or
>> add a separate paragraph to the wait rationale.
>
> If it works with "wait" in all shells (that we care about), then I
> agree it would
On 5/10/22 11:50 AM, Geoff Clare via austin-group-l at The Open Group wrote:
> Chet Ramey wrote, on 06 May 2022:
>>
>>>> And last, also in this area, is the question of stopped jobs and the wait
>>>> command, and how those two are intended to interact.
>>>
On 1/8/23 9:39 AM, Thorsten Glaser via austin-group-l at The Open Group wrote:
There are two questions here:
① Should shell script read errors be treated as EOF, as is practice?
② If not, what should the shell do upon encountering one?
It's pretty clear that a non-interactive shell can't
On 1/20/23 7:11 PM, Christoph Anton Mitterer via austin-group-l at The Open
Group wrote:
It's a pity, that the different parties often don't seem to try to
agree on something standardised first, but rather add new base
utilities or functionalities like the shell's "local"... and only
On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group
wrote:
bash appears to disables the reading of .profile in POSIX mode entirely.
This isn't quite correct. By default, a login shell named `sh' or `-sh'
reads /etc/profile and ~/.profile. You can compile bash for
On 3/14/23 4:58 PM, Harald van Dijk wrote:
On 14/03/2023 20:41, Chet Ramey wrote:
On 3/12/23 10:19 PM, Harald van Dijk via austin-group-l at The Open Group
wrote:
bash appears to disables the reading of .profile in POSIX mode entirely.
This isn't quite correct. By default, a login shell
On 2/24/23 11:35 AM, Harald van Dijk via austin-group-l at The Open Group
wrote:
I agree, but a subshell of an interactive shell is effectively
non-interactive anyway, and many of the special rules for interactive
shells should not apply to subshells of interactive shells and already
don't
On 2/24/23 10:59 AM, Robert Elz via austin-group-l at The Open Group wrote:
Can we agree (and then after Draft 3 is available, submit a bug report)
that this text should only apply to the top level of an interactive shell,
and not to any subshell environments.
I'd be good with specifying
On 4/6/23 5:43 PM, Robert Elz wrote:
Hence we got that absurd PATH search rule for builtins, that no shell of
the time did anything like, "because a user might want to override a
builtin with a version in their own bin directory, earlier in PATH than
where the standard version of the command
On 4/6/23 5:59 PM, Robert Elz wrote:
Date:Wed, 5 Apr 2023 10:35:58 -0400
From:"Chet Ramey via austin-group-l at The Open Group"
Message-ID:
| A variant with slightly different semantics:
|
| (exit 8)
| a=4 b=$(exit 42) c=$?
| echo stat
On 4/10/23 7:02 PM, Robert Elz wrote:
Date:Mon, 10 Apr 2023 10:30:08 -0400
From:Chet Ramey
Message-ID: <78038281-f431-775e-6d60-a44126d1d...@case.edu>
| The different semantics are that the standard specifies the status of the
| simple command in terms of
On 4/5/23 12:36 PM, Harald van Dijk wrote:
On 05/04/2023 15:35, Chet Ramey via austin-group-l at The Open Group wrote:
On 4/5/23 9:06 AM, Martijn Dekker via austin-group-l at The Open Group
wrote:
Consider:
false || echo $(true) $?
dash, mksh and yash print 1.
bash, ksh93 and zsh print
On 4/5/23 9:06 AM, Martijn Dekker via austin-group-l at The Open Group wrote:
Consider:
false || echo $(true) $?
dash, mksh and yash print 1.
bash, ksh93 and zsh print 0.
Which is right?
A variant with slightly different semantics:
(exit 8)
a=4 b=$(exit 42) c=$?
echo status:$? c=$c
On 4/6/23 1:55 PM, Harald van Dijk wrote:
One additional data point: in schily-2021-09-18, Jörg's last release,
obosh, the legacy non-POSIX shell that is just there for existing scripts
and for portability testing, prints 0 (using `` rather than $()), whereas
pbosh and sh, the minimal and
On 4/5/23 11:25 AM, Oğuz wrote:
5 Nisan 2023 Çarşamba tarihinde Chet Ramey via austin-group-l at The Open
Group mailto:austin-group-l@opengroup.org>>
yazdı:
but should it
be set fron the command substitution for the assignment to c?
I think it'd be practical, is there a reas
On 2/7/23 2:22 AM, Andrew Josey via austin-group-l at The Open Group wrote:
Bug 1629: Shell vs. read(2) errors on the script OPEN
https://austingroupbugs.net/view.php?id=1629
This item was discussed at length on the call
including the feedback from Chet Ramey. Notes were updated in
the
On 2/9/23 4:19 AM, Geoff Clare via austin-group-l at The Open Group wrote:
When this was discussed on the call, there was general agreement that
executing the partial line after getting a read error is really not
a good thing for shells to be doing.
OK, that's a reasonable position to take.
On 2/4/23 1:33 AM, Andrew Josey via austin-group-l at The Open Group wrote:
Bug 1629: Shell vs. read(2) errors on the script OPEN
https://austingroupbugs.net/view.php?id=1629
This item was discussed at length on the call.
We will continue with this item next time.
I looked at the etherpad.
On 2/14/24 12:06 AM, Oğuz wrote:
On Tuesday, February 13, 2024, Chet Ramey via austin-group-l at The Open
Group mailto:austin-group-l@opengroup.org>>
wrote:
`continue' is a builtin; continue has a return status; `!' says to
negate it. It seems easy to come to the conc
On 2/14/24 6:40 PM, Christoph Anton Mitterer wrote:
On Wed, 2024-02-14 at 09:18 -0500, Chet Ramey via austin-group-l at The
Open Group wrote:
POSIX requires this, since it says that return sets $? to 1 here.
I assume you mean the description of the exit status from `return`?
No, I mean
On 2/13/24 2:48 PM, Thorsten Glaser via austin-group-l at The Open Group wrote:
Hi,
I’ve got the following issue, and… yes I can see how the
reporter could come to the conclusion that it should “return”
1, but…
… at what point does “continue” “return”? Where do I stop
operating?
On 12/27/23 11:26 AM, Andrew Pennebaker via austin-group-l at The Open
Group wrote:
Many programs depend on hashmaps in order to work.
awk is not an answer.
The lack of hashmaps forces people to use less efficient algorithms, such
as linear search.
The bash family implements it. Simply
On 1/11/24 3:53 AM, Andrew Pennebaker via austin-group-l at The Open Group
wrote:
With sh gaining set -o pipefail, I am curious about having sh require (or
encourage) enabling this option by default. it would help to catch a lot of
false negatives in deceptively simple scripts.
No. This would
75 matches
Mail list logo
