please .. how what .. ?
On Thu, Jan 9, 2025, 11:15 PM Wiley Young wrote:
> On Wed, 8 Jan 2025 08:44:06 +1000,
> Martin D Kealey wrote:
>
> > I invite anyone to provide an example of how
>
> If the documentation changes at all, I think just a "See also..." might be
> enough.
>
> Wuley
>
On Wed, 8 Jan 2025 08:44:06 +1000,
Martin D Kealey wrote:
> I invite anyone to provide an example of how
If the documentation changes at all, I think just a "See also..." might be
enough.
Wuley
On 1/7/25 11:53 PM, Oğuz wrote:
A reminder that options enabled by the set command are inherited by
child shells when SHELLOPTS is exported
A sentence saying this is reasonable, if redundant.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita br
On Wednesday, January 8, 2025, Martin D Kealey
wrote:
>
> SHELLOPTS (such as debugging or delinting), but if it has no safe
> production use then perhaps that should be highlighted in the
> documentation.
>
Nah. A reminder that options enabled by the set command are inherited by
child shells when
On Tue, 7 Jan 2025, 21:24 Tobi Laskowski, wrote:
> the issue starts with misusing SHELLOPTS.
Some folk have taken issue with my suggestion that SHELLOPTS is broken by
design. Perhaps that was hyperbole, but it seems to me that if all possible
uses for a feature actually constitute misuses, then
> This is already documented in a couple of different places:
Thanks for providing the relevant sections. This makes sense having read things
more thoroughly, however, most people do not read documentation from top to
bottom. Someone looking for a way to enable a shell option globally will likel
> This precdence question is really the only one. Is this issue serious
> enough to change previous behavior in an incompatible way?
To me it seems most intuitive for flags to be applied after the environment
variable, but I do not mind too much about this.
> No. That is not consistent with the
On Jan 05 2025, Tobi Laskowski wrote:
> "It may be safe, however, it is a bit tedious...
Wow. I remember once I corrected an obvious flaw in a major project's CICD
bash scripts involving quoting and the trap builtin. You'd have thought I'd
have tried to chop somebody's fingers off.
Wiley
> | It is not possible to have a naive SHELLOPTS=myopt configured outside
> | the shell without all future options being exported implicitly.
> I have never used SHELLOPTS, and have never tested this, but:
> Does "unset SHELLOPTS" not work?
It gives:
bash: unset: SHELLOPTS: cannot unset
On 1/5/25 6:17 AM, Tobi Laskowski wrote:
This does not cover the specific behaviour I am concerned with. I would expect
something like:
"Additionally, if it is in the environment at start up, the variable is
automatically exported and shell options enabled subsequently through other means wil
On 1/4/25 2:47 PM, Tobi Laskowski wrote:
Hello,
I'd like to ask about an odd behaviour relating to the SHELLOPTS environment
variable. This is present in version 5.2.37(1)-release and in the development
version.
It's the behavior of every bash version going back to bash-2.0.
In this case,
On 1/5/25 5:10 AM, Koichi Murase wrote:
I confirmed this behavior, which I think is unreasonable.
$ (export SHELLOPTS; set -u; bash +u -c 'echo $unset')
bash: line 1: unset: unbound variable
I think an option explicitly specified in the command-line arguments
should take precedence over
On 1/5/25 8:09 AM, Robert Elz wrote:
Date:Sun, 5 Jan 2025 11:17:05 +
From:Tobi Laskowski
Message-ID:
| It is not possible to have a naive SHELLOPTS=myopt configured outside
| the shell without all future options being exported implicitly.
I have neve
On 1/5/25 5:13 AM, Oğuz wrote:
Maybe. I'm not sure if propagating shell options to child shells was the
intended primary use.
It was a long time ago (1995), but yes, that was one of the primary use
cases.
With ENV/BASH_ENV you can already do that and more, I
don't see the point in adding an
On 1/5/25 3:59 AM, Martin D Kealey wrote:
On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
This is documented in the manual:
In other words, it's broken by design.
You seem awfully sure of the correctness of your opinion.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
On Sun, Jan 05, 2025 at 19:10:41 +0900, Koichi Murase wrote:
> I confirmed this behavior, which I think is unreasonable.
>
> $ (export SHELLOPTS; set -u; bash +u -c 'echo $unset')
> bash: line 1: unset: unbound variable
>
> I think an option explicitly specified in the command-line arguments
Date:Sun, 5 Jan 2025 11:17:05 +
From:Tobi Laskowski
Message-ID:
| It is not possible to have a naive SHELLOPTS=myopt configured outside
| the shell without all future options being exported implicitly.
I have never used SHELLOPTS, and have never tested this
On Jan 05 2025, Tobi Laskowski wrote:
> "Additionally, if it is in the environment at start up, the variable is
> automatically exported
That is a general property of every environment variable.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73
>> On the other hand, if there is a pre-existing SHELLOPTS environment variable
>> (set outside the current shell), then the `nounset` option applies to all
>> invocations of bash within the current shell.
> This is documented in the manual:
>> A colon-separated list of enabled shell options.
>
On Sunday, January 5, 2025, Martin D Kealey wrote:
>
> In other words, it's broken by design.
>
Maybe. I'm not sure if propagating shell options to child shells was the
intended primary use. With ENV/BASH_ENV you can already do that and more, I
don't see the point in adding an environment variabl
2025年1月5日(日) 5:43 Tobi Laskowski :
> On the other hand, if there is a pre-existing SHELLOPTS environment
> variable (set outside the current shell), then the `nounset` option
> applies to all invocations of bash within the current shell.
This is documented as Oguz pointed out.
> Even with the `+u
At 2025-01-05T18:59:57+1000, Martin D Kealey wrote:
> On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
> > This is documented in the manual:
>
> In other words, it's broken by design.
Well, pull out of your back pocket what you've been coyly keeping from
us--a programming language that occupies global o
On Sun, 5 Jan 2025 at 15:18, Oğuz wrote:
> This is documented in the manual:
>
In other words, it's broken by design.
> Try BASH_ENV instead:
>
> https://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html#index-BASH_005fENV
>
Don't forget ENV as well, for sh scripts.
-Martin
On Saturday, January 4, 2025, Tobi Laskowski wrote:
>
> On the other hand, if there is a pre-existing SHELLOPTS environment
> variable (set outside the current shell), then the `nounset` option applies
> to all invocations of bash within the current shell.
This is documented in the manual:
> A
24 matches
Mail list logo
