On Saturday, August 24, 2024, Andrew Pennebaker via austin-group-l at The
Open Group wrote:
>
> Same question for linkers (ld program, .ld files), and for assemblers as
> well (cc program, .asm files).
>
> I think it's an interesting historical quirk that make has built-in rules
> for lex and yacc
On Monday, July 8, 2024, наб wrote:
>
> I'm gonna take this at face value, but 2.13 Shell Execution Environment
> doesn't mention signal dispositions either,
It does:
If the utility is a shell script, traps caught by the shell shall be set to
the default values and traps ignored by the shell sh
On Mon, Jul 8, 2024 at 1:05 AM наб via austin-group-l at The Open Group <
austin-group-l@opengroup.org> wrote:
> timeout is allowed to unignore SIGALRM, can it unblock SIGALRM too?
The signal mask is not part of execution environments invoked by the shell.
So it's unspecified whether timeout (or a
On Saturday, June 29, 2024, наб via austin-group-l at The Open Group <
austin-group-l@opengroup.org> wrote:
>
> This is a reasonable read I think.
XBD 3.129 describes an executable file as follows:
A regular file acceptable as a new process image file by the equivalent of
the exec family of func
On Friday, June 21, 2024, наб via austin-group-l at The Open Group <
austin-group-l@opengroup.org> wrote:
>
> Maybe add something to the effect of ", except the starting location
> in the file shall be measured in lines or partial lines instead of bytes."?
>
See the INPUT FILES section. It says:
On Thursday, February 15, 2024, Harald van Dijk via austin-group-l at The
Open Group wrote:
>
> Because the eval command parses a command from a string, here, the second
> ! is not part of the last pipeline. The last pipeline is just "break". The
> "eval" command's exit status would be negated, bu
On Wed, Feb 14, 2024 at 11:08 AM Harald van Dijk wrote:
> I still see a difference between yash 2.53 and 2.54, not 2.54 and
> 2.55
Must be an error on my part
> but in dash, gwsh, and yash alike, it looks like it is that same
> fix for the return command that also affected the break and continue
On Wed, Feb 14, 2024 at 9:58 AM Harald van Dijk wrote:
> The test script with 'return'?
I mean this one:
for x in y; do
! continue
done
echo $?
On Wed, Feb 14, 2024 at 8:47 AM Harald van Dijk wrote:
> POSIX specifies:
>
> > The value of the special parameter '?' shall be set to n, an unsigned
> decimal integer, or to the exit status of the last command executed if n
> is not specified.
>
> In your example, n is 1, therefore $? shall be s
On Tuesday, February 13, 2024, Chet Ramey via austin-group-l at The Open
Group wrote:
>
> `continue' is a builtin; continue has a return status; `!' says to
> negate it. It seems easy to come to the conclusion that the script
> should return 1.
>
The same can be said about `return'. But bash disa
On Wednesday, December 27, 2023, Andrew Pennebaker <
andrew.penneba...@gmail.com> wrote:
> Simply acknowledging bash associative array syntax, would instantly
> improve the scalability of sh scripts.
>
.. in theory. Other shells would have to implement it first. Considering
some of them don't eve
On Wednesday, December 27, 2023, Andrew Pennebaker via austin-group-l at
The Open Group wrote:
> I am currently using dynamically named variables in order to implement
> logical hashmaps in pure, POSIX sh.
>
Why? The standard hashmap language is AWK and it's available on every
POSIX-compliant sy
Yeah, exactly. Thanks for this very interesting discussion. Bye
On Thursday, October 26, 2023, Gabriel Ravier wrote:
> On 10/26/23 11:55, Oğuz wrote:
>
>> On Wed, Oct 25, 2023 at 9:47 PM Gabriel Ravier
>> wrote:
>> > Isn't this a similar situation to e.g. `getuid`/`geteuid`/etc. failures
>>
>>
On Wed, Oct 25, 2023 at 9:47 PM Gabriel Ravier wrote:
> Isn't this a similar situation to e.g. `getuid`/`geteuid`/etc. failures
Not similar enough to draw a conclusion. Unlike system(), those functions
are not part of the language defined by ISO C, but the operating system
interface defined by PO
Oğuz
On Tue, Oct 24, 2023 at 1:53 PM Jonathan Wakely wrote:
>
>
>
> On Tue, 24 Oct 2023 at 07:10, Oğuz via austin-group-l at The Open Group
> wrote:
>>
>> On Tuesday, October 24, 2023, enh via austin-group-l at The Open Group
>> wrote:
>>>
>>
On Tuesday, October 24, 2023, enh via austin-group-l at The Open Group <
austin-group-l@opengroup.org> wrote:
> netbsd checks that _PATH_BSHELL is exectuable with access(2)
> (but doesn't actually _execute_ anything). apple's copy of freebsd has
> a local change similar to the netbsd one. glibc se
On Fri, Sep 1, 2023 at 10:12 AM Stephane Chazelas wrote:
> Yes, though note:
>
> - that implies forking a process and loading an external
> executable and its libraries
The standard doesn't mandate that printf be a builtin; so, in
principle, this might be the case with printf as well.
> - bc i
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 place?
7 Nisan 2023 Cuma tarihinde Robert Elz via austin-group-l at The Open Group
yazdı:
> My guess (no more than that) is that sometimes it is easier to
> give in to the desires of the masses rather than maintain the
> correct approach.
>
> To people who don't understand sh syntax,
>
> a=1 b=2
5 Nisan 2023 Çarşamba tarihinde Harald van Dijk yazdı:
> There is a legitimate benefit to this: swapping variables without an
> additional helper variable actually works in that implementation.
Good point, thanks
--
Oğuz
5 Nisan 2023 Çarşamba tarihinde Harald van Dijk yazdı:
> I am not sure which other ash based shells you were looking at,
/bin/sh on NetBSD and FreeBSD
--
Oğuz
5 Nisan 2023 Çarşamba tarihinde Chet Ramey via austin-group-l at The Open
Group yazdı:
> but should it
> be set fron the command substitution for the assignment to c?
I think it'd be practical, is there a reason why it shouldn't? And while
we're at it, is there a reason why assignments in a sim
30 Aralık 2022 Cuma tarihinde Christoph Anton Mitterer <
cales...@scientia.org> yazdı:
> Which, if it's only written in the exit built-in’s description, could
> still be mistaken as "only when via done so via a call to the exit
> utility" - and e.g. not if the script reaches EOF.
I don't think s
31 Ağustos 2022 Çarşamba tarihinde Lawrence Velázquez via austin-group-l at
The Open Group yazdı:
>
> Do lines 2857 through 2877 not address this sufficiently?
They do
--
Oğuz
3 Nisan 2022 Pazar tarihinde Christoph Anton Mitterer via austin-group-l at
The Open Group yazdı:
>
> But many of those extensions made by implementations in areas where
> POSIX doesn't define things, cause IMO quite some trouble in practise.
>
Such as?
--
Oğuz
14 Ocak 2022 Cuma tarihinde Christoph Anton Mitterer
yazdı:
> Which is impossible again, especially in a portable manner, when it's
> ambiguous what a valid RE is.
Except it's not. Use a delimiter that doesn't appear in the RE and you're
good.
> But since it is neither specified how the parsi
On Fri, Jan 14, 2022 at 11:10 AM Don Cragun wrote:
> It isn't that simple. The string between the first and second delimiters in
> a substitute command has to be an RE (and "[" can't be the end of an RE; it
> is the start of a bracket expression). Note also that is not
> special inside a bra
On Thu, Jan 13, 2022 at 6:36 PM Christoph Anton Mitterer
wrote:
> And where does it say that? I mean in the standard.
> I.e. where does it say, that parsing is only allowed to happen in one
> stage from left to right, especially not only with respect to an RE
> itself, but also when an RE is embed
Clicked Reply instead of Reply All, sorry.
-- Forwarded message -
From: Oğuz
Date: Thu, Jan 13, 2022 at 9:40 AM
Subject: Re: sed and delimiters that are also special characters to REs
To: Christoph Anton Mitterer
On Tue, Jan 11, 2022 at 1:15 AM Christoph Anton Mitterer via
aust
17 Aralık 2021 Cuma tarihinde Quentin Rameau via austin-group-l at The Open
Group yazdı:
>
> The standard could state that the result of trying to expand an unset
> macro is implementation-defined,
>
But that's not the case; the widely-adopted behavior is that unset macros
expand to empty string.
22 Ekim 2021 Cuma tarihinde Stephane Chazelas via austin-group-l at The
Open Group yazdı:
> 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
10 Eylül 2021 Cuma tarihinde Robert Elz yazdı:
>
> But the third argument is c the first time around.
> Why would that be replaced by '' ?
> It is then, perhaps, '' the next iteration of the format string.
>
I should have said "the current subset of arguments being processed" or
something like th
10 Eylül 2021 Cuma tarihinde Robert Elz via austin-group-l at The Open
Group yazdı:
>
> When %n$ was added to those implementations of printf which support it,
> it seems to have been added in the simplest way possible - printf simply
> picks the identified arg, instead of the "next" one, and the
8 Eylül 2021 Çarşamba tarihinde Harald van Dijk yazdı:
> On 08/09/2021 08:15, Oğuz via austin-group-l at The Open Group wrote:
>
>> Sorry for butting in, but according to the standard, is there really a
>> syntax error in the following?
>>
>> sh -c ': <&
Sorry for butting in, but according to the standard, is there really a
syntax error in the following?
sh -c ': << do | for x in xxx
do
do echo $x
done'
busybox sh, dash, gwsh, netbsd sh, and freebsd sh complain about a
missing `done'.
1 Eylül 2021 Çarşamba tarihinde Robert Elz yazdı:
> Date:Wed, 1 Sep 2021 16:38:00 +0300
> From:"=?UTF-8?B?T8SfdXo=?= via austin-group-l at The Open
> Group"
> Message-ID: qvsysq5nfzfxetr7yeq...@mail.gmail.com>
>
> | true
> | a=$? b=`exit 1` b=$? >`echo /dev/null
Consider the following:
true
a=$? b=`exit 1` b=$? >`echo /dev/null; exit 2`
echo $? $a $b
Having read the relevant sections of the standard a couple times, I
would expect the output to be `1 0 0'; but that's not the case with
most shells. Below are what each shell I have on my computer output
for
30 Haziran 2021 Çarşamba tarihinde L A Walsh via austin-group-l at The Open
Group yazdı:
>
> Anyway, it is the parent that is directed the output to a location that
> won't work as an output destination. In my example with >/dev/zero, I
> got a permission denied from the parent process. If I had
On Mon, Apr 26, 2021 at 12:26 PM Geoff Clare via austin-group-l at The
Open Group wrote:
>
> Oğuz wrote, on 25 Apr 2021:
> >
> > On Sat, Apr 24, 2021 at 6:22 PM Austin Group Bug Tracker via
> > austin-group-l at The Open Group wrote:
> > > $ echo 'x,,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print
(Replying to the list because I don't have write access to the bug tracker.)
On Sat, Apr 24, 2021 at 6:22 PM Austin Group Bug Tracker via
austin-group-l at The Open Group wrote:
> $ echo 'x,,z' | awk -F'[^,]*' '{for (i=1;i<=NF;i++) print i, "<"$i">"}'
> 1 <>
> 2 <,,>
> 3 <>
This seems rather lik
16 Nisan 2021 Cuma tarihinde Philip Guenther via austin-group-l at The Open
Group yazdı:
>
> Did I miss a statement about somewhere that renders this
> behavior unspecified?
>
P1003.1™-202x/D1.1 Page 3036, Line 102784:
> The interpretation of a followed by any other sequence of
characters is un
12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at
The Open Group yazdı:
>
> > On Apr 12, 2021, at 1:51 PM, Oğuz wrote:
> > Taking "always double-quote your dollar variables", "eval is evil, avoid
> it", etc. as "the rule" is cargo cult programming. Average programmer's
> i
12 Nisan 2021 Pazartesi tarihinde David A. Wheeler
yazdı:
>
>
> On Apr 12, 2021, at 10:57 AM, Oğuz wrote:
> 12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at
> The Open Group yazdı:
>>
>> If you want a robust shell script, I recommend that you try out the tool
>> “shellch
12 Nisan 2021 Pazartesi tarihinde David A. Wheeler via austin-group-l at
The Open Group yazdı:
>
> If you want a robust shell script, I recommend that you try out the tool
> “shellcheck”.
> That checks a shell script against a set of recommended practices (e.g.,
> use “$variable” not $variable).
>
On Sun, Apr 11, 2021 at 1:47 PM shwaresyst via austin-group-l at The Open
Group wrote:
> That's bugs in those shells for POSIX mode then, that I see. The
> conforming behavior is /usr/gcc is found and succeeds at doing nothing,
> since it contains just a comment line. Other elements of path never
On Mon, Apr 5, 2021 at 4:22 PM Austin Group Bug Tracker via austin-group-l
at The Open Group wrote:
>
> The following issue has been SUBMITTED.
> ==
> https://austingroupbugs.net/view.php?id=1464
> ===
6 Ağustos 2020 Perşembe tarihinde Oğuz yazdı:
>
>
> 5 Ağustos 2020 Çarşamba tarihinde Michael Kerrisk (man-pages) <
> mtk.li...@gmail.com> yazdı:
>
>> On 8/5/20 7:12 PM, Oğuz via austin-group-l at The Open Group wrote:
>> > 5 Ağustos 2020 Çarşamba tarihinde
5 Ağustos 2020 Çarşamba tarihinde Michael Kerrisk (man-pages) <
mtk.li...@gmail.com> yazdı:
> On 8/5/20 7:12 PM, Oğuz via austin-group-l at The Open Group wrote:
> > 5 Ağustos 2020 Çarşamba tarihinde Robert Elz via austin-group-l at The
> Open
> > Group yazdı:
> >
5 Ağustos 2020 Çarşamba tarihinde Robert Elz via austin-group-l at The Open
Group yazdı:
> Date:Wed, 05 Aug 2020 11:28:45 -0400
> From:"Paul Smith via austin-group-l at The Open Group" <
> austin-group-l@opengroup.org>
> Message-ID: <1d8c5e6e96fbdd47ce143a566b57db2c80
49 matches
Mail list logo
