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
Martijn Dekker via austin-group-l at The Open Group dixit:
> Today I received a pull request to make allexport work for ${var:=value} and
> ${var=value} on ksh 93u+m. This currently works on bash, dash, *BSD sh, and
> zsh, but not on ksh, pdksh/mksh, or yash.
mksh does so because AT ksh does;
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
All
These are the minutes of yesterday’s call.
regards
Andrew
Minutes of the 27th January 2022 TeleconferenceAustin-1193 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 28th January 2022
Attendees:
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1546
==
Reported By:calestyo
Assigned To:
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1558
==
Reported By:stephane
Assigned To:
Hans Åberg dixit:
>It would be better to use astronomical year numbering.
>
>https://en.wikipedia.org/wiki/Astronomical_year_numbering
Isn’t that just the proleptic Gregorian calendar, as used
by struct tm (tm_year is “years since 1900”) already anyway?
But in the text example I was thinking of
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
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
Christoph Anton Mitterer via austin-group-l at The Open Group dixit:
>However, that may have been crashed again by [2] respectively [3].
|it actually finds "XL"? One possible behavior is to replace "XL" with
|"" where is a replacement character such as "�"
I’d say this is a bug. It should
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1558
==
Reported By:stephane
Assigned To:
On Fri, 2022-01-28 at 11:26 +, mirabilos wrote:
> Christoph Anton Mitterer via austin-group-l at The Open Group dixit:
>
> > However, that may have been crashed again by [2] respectively [3].
>
> |it actually finds "XL"? One possible behavior is to replace "XL"
> with
> |"" where is a
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 ^^
>
A NOTE has been added to this issue.
==
https://www.austingroupbugs.net/view.php?id=1546
==
Reported By:calestyo
Assigned To:
15 matches
Mail list logo
