Hey.
I'm still trying to write up some in-depth documentation (e.g. for
StackOverflow) why things (i.e. the command substitution with trailing
newlines) work the way (and have to be the way), as it was described
here before.
And unfortunately, stumbled over some more...
1)
a) As per POSIX,
Hey Eric.
On Tue, 2022-02-08 at 15:21 -0600, Eric Blake wrote:
> Yes. And another fallout of that requirement: you cannot have a
> single
> POSIX system supporting both ASCII and EBCDIC locales.
What does that mean in practise... does e.g. Linux/glibc ship these
locales just for the purpose of
On Tue, Feb 08, 2022 at 06:53:50AM +0100, Christoph Anton Mitterer via
austin-group-l at The Open Group wrote:
> Hey.
>
> I'm afraid but some more questions came up on my side:
>
>
> 1) POSIX says:
> "The encoded values associated with , , , and
> shall be invariant across all locales
Hey.
I'm afraid but some more questions came up on my side:
1) POSIX says:
"The encoded values associated with , , , and
shall be invariant across all locales supported by
the implementation."
When now, for example, is encoded as the byte 0x2E ... the
consequence would be that it had to be
On Mon, 2022-01-31 at 10:45 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> >
> Okay, I was assuming the typical case where the output is only
> valid for exit status 0. If other exit statuses also have valid
> output then they would need to be allowed for (such as grep
> exiting
Christoph Anton Mitterer wrote, on 29 Jan 2022:
>
> On Fri, 2022-01-28 at 09:51 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
>
> > Also, having carefully arranged the exit
> > status you want, you don't do anything with it.
> That I don't understand?
There is nothing in your
On Sat, 2022-01-29 at 01:00 +0100, Christoph Anton Mitterer wrote:
> What about:
> result="$(some_command ; e=$?; print '.' && exit $e || exit 666 )"
Dammit... it's my notebook's "f" key... starts to stop working.
result="$(some_command ; e=$?; printf '.' && exit $e || exit 666 )"
On Fri, 2022-01-28 at 09:51 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> > result="$(command ; e=$?; print '.' ; exit $?)"
>
> The print should be printf, and I assume you intended exit $e here.
Of course... sorry,... shouldn't write such things late in the night ^^
>
On 28/01/2022 01:49, Christoph Anton Mitterer wrote:
And hasn't it always been the case that stdout/in can contain arbitrary
binary data?
This is done by gazillions of tools, including such standardised by
POSIX (cat, tr, even printf via \ooo sequences).
Yes, but it has also been the case that
Christoph Anton Mitterer wrote, on 28 Jan 2022:
>
> And just for the record if anyone else should ever stumble over that
> thread here in the archives... this is what I'd consider *the* solution
> which works in any POSIX compatible shell (and there in any scope,
> global or function) that handles
On 28/01/2022 01:48, Christoph Anton Mitterer wrote:
On Thu, 2022-01-27 at 15:18 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
The benefit of this that when the
shell's locale changes, variables still hold their original text (as
opposed to their original bytes).
But
On 28/01/2022 01:49, Christoph Anton Mitterer wrote:
On Thu, 2022-01-27 at 17:07 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
That is not what POSIX says. It says "The value of an environment
variable is a string of characters" (8.1 Environment Variable
Definition), and
On Thu, 2022-01-27 at 12:44 +, Geoff Clare via austin-group-l at
The Open Group wrote:
>
> It seems to me that there are three cases to consider:
>
> * The command's output is expected to contain byte sequences that
> might not form valid characters.
> In this case LC_ALL=C should be
On Thu, 2022-01-27 at 18:09 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
>
> I have to disagree. The use of " character" to me clearly
> means
> that the output of the command is processed as a sequence of
> characters,
> as opposed to a sequence of bytes.
While not being
On Thu, 2022-01-27 at 17:07 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
> That is not what POSIX says. It says "The value of an environment
> variable is a string of characters" (8.1 Environment Variable
> Definition), and "character" is defined as "a sequence of one or
On Thu, 2022-01-27 at 15:18 +, Harald van Dijk via austin-group-l
at The Open Group wrote:
> The benefit of this that when the
> shell's locale changes, variables still hold their original text (as
> opposed to their original bytes).
But doesn't that by itself already violate POSIX?
There
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 27/01/2022 17:43, Geoff Clare via austin-group-l at The Open Group wrote:
Harald van Dijk wrote, on 27 Jan 2022:
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
Harald van Dijk wrote, on 27 Jan 2022:
>
> 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 to store?
> > > I only
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 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 the `=' is a
valid NAME, the shell is required to create a variable with 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 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 to store?
I only found that NUL is excluded, but that alone doesn't mean that
Christoph Anton Mitterer wrote, on 26 Jan 2022:
>
> On Tue, 2022-01-25 at 09:25 +, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > You are correct, and a common method of preserving trailing newlines
> > is to append a non-newline character and then strip it, e.g.:
> >
> >
Hey Geoff.
Thanks and funny you came up with that...
On Tue, 2022-01-25 at 09:25 +, Geoff Clare via austin-group-l at
The Open Group wrote:
> You are correct, and a common method of preserving trailing newlines
> is to append a non-newline character and then strip it, e.g.:
>
>
25 matches
Mail list logo
