Op 29-02-2024 om 18:56 schreef Harald van Dijk: > Good point, though by special-casing getopts and read, it kind of > implies that it does not apply to other commands and utilities. I'd forgotten I'd filed an Austin Group bug for this about two years ago: https://www.austingroupbugs.net/view.php?id=1555 It was resolved that the text in the next version of the standard will be: | Set the export attribute for all variable assignments. When this option | is on, whenever a value is assigned to a variable in the current shell | execution environment, the export attribute shall be set for the variable. | This applies to all forms of assignment, including those made as a | side-effect of variable expansions or arithmetic expansions, and those made | as a result of the operation of the cd, getopts, or read utilities. | | <small>Note: As discussed in Section 2.9.1, not all variable assignments | happen in the current execution environment. When an assignment happens in | a separate shell execution environment, the export attribute is still set | for the variable, but that does not affect the current shell execution | environment.</small> HTH. -- || modernish -- harness the shell || https://github.com/modernish/modernish || || KornShell lives! || https://github.com/ksh93/ksh
Hi, On 08/03/2024 11:01, Johannes Altmanninger wrote: > TL;DR: I think this job should exit on Control-C. > > ( trap - INT; sleep inf ) & The TL;DR is oversimplified: Control-C would not result in SIGINT being sent to the sleep command, because it runs in the background. Your fuller version, I agree, I think that is a bug in dash. There are some more known bugs in its handling of the trap command in subshells that require a bigger rework (particularly the one where, despite traps being reset in subshells, the 'trap' command should print the parent shell's traps if called in a subshell) that maybe should be looked at at the same time. > In general, I wonder if SIGINT is only for actual shells, and SIGTERM > is the signal to use in our situation. SIGINT is not limited to shells. At first glance, sending SIGINT to another process or process group upon receipt of SIGINT, because that other process or process group is what it was intended for, seems like an appropriate use to me. Cheers, Harald van Dijk
TL;DR: I think this job should exit on Control-C. ( trap - INT; sleep inf ) & With shell=bash or shell=zsh this works with below script. Meanwhile, shell=dash fails shell=dash set -e n=123 pkill -f "sleep.$n" ||: pid=$(setsid "$shell" -c "( trap - INT; sleep $n ) </dev/null >/dev/null 2>&1 & echo \$\$") sleep 1 kill -INT -$pid ps aux | grep "[s]leep.$n" POSIX[*] Section 2.11 on Signals and Error Handling says about background execution: > If job control is disabled (see the description of set -m) when > the shell executes an asynchronous list, the commands in the list > shall inherit from the shell a signal action of ignored (SIG_IGN) > for the SIGINT and SIGQUIT signals. and continues: > In all other cases, commands executed by the shell shall inherit the > same signal actions as those inherited by the shell from its parent > unless a signal action is modified by the trap special built-in > (see trap) It is not clear to me whether the trap builtin is supposed to override the ignore. Intuitively, I'd say yes, and the Bash maintainer seems to agree responding to a related bug report about Bash functions[**] > The issue is that the processes in this list have to ignore SIGINT > [...] but they have to be allowed to use trap to change the signal > dispositions (POSIX interp 751) Attached patch works for me though it's barely thought-through or tested. Happy to take it to completion. [*]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html [**]: https://lists.gnu.org/archive/html/bug-bash/2023-01/msg00050.html {{{ Backstory: The Kakoune[1] editor likes to run shell commands that boil down to mkfifo /tmp/fifo ( sleep inf # in practice "make" ) >/tmp/fifo 2>&1 & On Control-C, the editor traditionally sends SIGINT to the process group. Bash documentation says[2]: > When job control is not in effect, asynchronous commands ignore > SIGINT and SIGQUIT in addition to these inherited handlers. This means that the "sleep inf" process ignores SIGINT. We have worked around this fact by sending SIGTERM instead[3]. If the forked process sets a SIGINT handler of any form, for example by using "signal(SIGINT, SIG_DFL)", it will no longer ignore SIGINT. It seems reasonable to give (sub)shells the same powers, via the "trap" builtin. This would allow me to change the above subshell to ( trap - INT sleep inf ) >/tmp/fifo 2>&1 & to have it be terminated by SIGINT. In general, I wonder if SIGINT is only for actual shells, and SIGTERM is the signal to use in our situation. [1]: https://kakoune.org/ [2]: https://www.gnu.org/software/bash/manual/html_node/Signals.html [3]: https://lists.sr.ht/~mawww/kakoune/%3C20240307135831.1967826-3-aclopte@gmail.com%3E }}} --- src/trap.c | 12 +++++++++--- src/trap.h | 1 + 2 files changed, 10 insertions(+), 3 deletions(-) diff --git a/src/trap.c b/src/trap.c index cd84814..a6778e8 100644 --- a/src/trap.c +++ b/src/trap.c @@ -159,7 +159,7 @@ trapcmd(int argc, char **argv) } trap[signo] = action; if (signo != 0) - setsignal(signo); + setsignal_maybe_user(signo, 1); INTON; ap++; } @@ -175,6 +175,12 @@ trapcmd(int argc, char **argv) void setsignal(int signo) +{ + setsignal_maybe_user(signo, 0); +} + +void +setsignal_maybe_user(int signo, int user) { int action; int lvforked; @@ -234,7 +240,7 @@ setsignal(int signo) } if (act.sa_handler == SIG_IGN) { if (mflag && (signo == SIGTSTP || - signo == SIGTTIN || signo == SIGTTOU)) { + signo == SIGTTIN || signo == SIGTTOU)) { tsig = S_IGN; /* don't hard ignore these */ } else tsig = S_HARD_IGN; @@ -242,7 +248,7 @@ setsignal(int signo) tsig = S_RESET; /* force to be set */ } } - if (tsig == S_HARD_IGN || tsig == action) + if ((!user && tsig == S_HARD_IGN) || tsig == action) return; switch (action) { case S_CATCH: diff --git a/src/trap.h b/src/trap.h index beaf660..595992c 100644 --- a/src/trap.h +++ b/src/trap.h @@ -43,6 +43,7 @@ extern volatile sig_atomic_t gotsigchld; int trapcmd(int, char **); void setsignal(int); +void setsignal_maybe_user(int, int); void ignoresig(int); void onsig(int); void dotrap(void); -- 2.44.0.rc1.17.g3e0d3cd5c7
On Thu, 2024-02-29 at 17:58 +0000, Martijn Dekker wrote:
> No shell currently behaves like that, and it would make no sense, as
> 'unset'
> and 'empty value' are distinct states.
Well in the end I don't mind what's done, but would prefer that the
specs unambiguously describe it, and even if just says that the
behaviour is unspecified.
People read it, and by just reading the description of the export tool
one might conclude, that such variable is exported to the environment
of an executed command.
Cheers,
Chris.
On 29/02/2024 18:45, Martijn Dekker wrote:
> Op 29-02-2024 om 18:07 schreef Harald van Dijk:
>> On 29/02/2024 17:41, Martijn Dekker wrote:
>>> Op 28-02-2024 om 00:56 schreef Harald van Dijk:
>>>> However, trying to fix this I come across a corner case where it is
>>>> not clear to me what the intended behaviour is.
>>>>
>>>> set -a; readonly foo=bar; export # some shells export, not all
>>>
>>> IMO, the shell should export it in that case; POSIXly, 'set -a'
>>> should cause the variable to be exported whenever a value is
>>> effectively assigned to it (whether this is by a "true" shell
>>> assignment, an assignment-argument, an expansion like ${foo=bar} or
>>> ${foo:=bar}, indirectly by 'read' or 'getopts', or maybe other cases
>>> I'm not thinking of).
>>
>> Spec-wise, the thing that troubles me is that the option is specified as
>>
>> > When this option is on, the export attribute shall be set for each
>> > variable to which an assignment is performed; see XBD Variable
>> > Assignment.
>>
>> where XBD Variable Assignment is only about the assignment syntax of
>> the shell, not other syntax or other commands even if they also cause
>> variables to become assigned.
>
> Yeah, that's confusing (and IMO should be fixed in the spec), but that
> same paragraph goes on to mention 'getopts' and 'read' as examples of
> utilities that perform assignments. In other words, though 'read var' is
> no XBD "Variable Assignment" assignment, it's stated explicitly that
> 'var', on which 'read' performs an assignment, should gain the export
> attribute.
Good point, though by special-casing getopts and read, it kind of
implies that it does not apply to other commands and utilities.
Anyway, now that I think we are on the same page about what shells
*should* do: in dash, a quick search suggests this should be the following:
* Substitutions may perform assignment (the ones you mentioned, plus
$((...)) arithmetic)
* The for command performs assignments to the loop variable.
* The cd command sets PWD and OLDPWD.
* The getopts command does not merely assign to the specified variable,
also to OPTARG and OPTIND.
* The local and readonly commands perform assignments to specified
variables.
* Every command causes a value to be assigned to LINENO.
* Every simple command causes a value to be assigned to _.
The way I implemented LINENO, the implicit export does not work for
that, and for consistency, it should, even if no one is going to be
relying on that. I have not gone over the other ones to check if they
are all handled correctly.
Cheers,
Harald van Dijk
Op 29-02-2024 om 18:07 schreef Harald van Dijk: > On 29/02/2024 17:41, Martijn Dekker wrote: >> Op 28-02-2024 om 00:56 schreef Harald van Dijk: >>> However, trying to fix this I come across a corner case where it is not >>> clear to me what the intended behaviour is. >>> >>> set -a; readonly foo=bar; export # some shells export, not all >> >> IMO, the shell should export it in that case; POSIXly, 'set -a' should cause >> the variable to be exported whenever a value is effectively assigned to it >> (whether this is by a "true" shell assignment, an assignment-argument, an >> expansion like ${foo=bar} or ${foo:=bar}, indirectly by 'read' or 'getopts', >> or maybe other cases I'm not thinking of). > > Spec-wise, the thing that troubles me is that the option is specified as > > > When this option is on, the export attribute shall be set for each > > variable to which an assignment is performed; see XBD Variable > > Assignment. > > where XBD Variable Assignment is only about the assignment syntax of the > shell, not other syntax or other commands even if they also cause variables to > become assigned. Yeah, that's confusing (and IMO should be fixed in the spec), but that same paragraph goes on to mention 'getopts' and 'read' as examples of utilities that perform assignments. In other words, though 'read var' is no XBD "Variable Assignment" assignment, it's stated explicitly that 'var', on which 'read' performs an assignment, should gain the export attribute. -- || modernish -- harness the shell || https://github.com/modernish/modernish || || KornShell lives! || https://github.com/ksh93/ksh
On 29/02/2024 17:41, Martijn Dekker wrote:
> Op 28-02-2024 om 00:56 schreef Harald van Dijk:
>> However, trying to fix this I come across a corner case where it is
>> not clear to me what the intended behaviour is.
>>
>> set -a; readonly foo=bar; export # some shells export, not all
>
> IMO, the shell should export it in that case; POSIXly, 'set -a' should
> cause the variable to be exported whenever a value is effectively
> assigned to it (whether this is by a "true" shell assignment, an
> assignment-argument, an expansion like ${foo=bar} or ${foo:=bar},
> indirectly by 'read' or 'getopts', or maybe other cases I'm not thinking
> of).
Spec-wise, the thing that troubles me is that the option is specified as
> When this option is on, the export attribute shall be set for each
> variable to which an assignment is performed; see XBD Variable
> Assignment.
where XBD Variable Assignment is only about the assignment syntax of the
shell, not other syntax or other commands even if they also cause
variables to become assigned.
That said, I think I agree that this just does not make sense, and even
if the spec says this, it is not what current versions of shells
including bash and dash do, so even if my reading of the spec is
correct, that makes it a spec bug, not a shell bug, and dash should not
change behaviour here. (Of course, the originally reported bug should
still be fixed.)
Cheers,
Harald van Dijk
Op 29-02-2024 om 12:24 schreef Christoph Anton Mitterer: [...] > One might also argue like this: > * -a says "the export attribute shall be set for each variable to which > an assignment is performed". Further on, that same paragraph also contains: | [...] or if the assignment is a result of the operation of the getopts or | read utilities, the export attribute shall persist until the variable is | unset. So 'getopts' and 'read' are two examples of where the variable should be exported, and neither do an explicit shell assignment. While the language is indeed not very clear, this implies that the variable should indeed be exported in all cases where a variable assignment is actually performed. AT&T ksh 93u+ was also broken in this regard. In ksh 93u+m, I've fixed it by moving the 'set -a' functionality into nv_putval(), its central shell assignment function, so that the variable gets exported whenever the shell performs an assignment for any reason and in any context. -- || modernish -- harness the shell || https://github.com/modernish/modernish || || KornShell lives! || https://github.com/ksh93/ksh
Op 28-02-2024 om 00:56 schreef Harald van Dijk: > However, trying to fix this I come across a corner case where it is not > clear to me what the intended behaviour is. > > set -a; readonly foo=bar; export # some shells export, not all IMO, the shell should export it in that case; POSIXly, 'set -a' should cause the variable to be exported whenever a value is effectively assigned to it (whether this is by a "true" shell assignment, an assignment-argument, an expansion like ${foo=bar} or ${foo:=bar}, indirectly by 'read' or 'getopts', or maybe other cases I'm not thinking of). -- || modernish -- harness the shell || https://github.com/modernish/modernish || || KornShell lives! || https://github.com/ksh93/ksh
Op 29-02-2024 om 12:29 schreef Christoph Anton Mitterer: > On Tue, 2024-02-27 at 02:53 -0500, Lawrence Velázquez wrote: >> That's my understanding: Environment variables must have values >> (even empty ones), so unset shell variables cannot be placed into >> the environment. One might propose that a valueless environment >> variable could be represented as "name", but the standard requires >> that environment strings contain a "=". > > And yet: >> The shell shall give the export attribute to the variables >> corresponding to the specified names, which shall cause them to be >> in the environment of subsequently executed commands. > > would IMO mean that export attribute alone decides whether it's > exported or not - not whether it has a set value. No shell currently behaves like that, and it would make no sense, as 'unset' and 'empty value' are distinct states. However, the variable will be exported once a value is subsequently assigned to it, without the need to re-invoke 'export'. $ unset foo; export foo; printenv foo # not yet actually exported $ foo=bar; printenv foo # but now it is -- || modernish -- harness the shell || https://github.com/modernish/modernish || || KornShell lives! || https://github.com/ksh93/ksh
On Tue, 2024-02-27 at 02:53 -0500, Lawrence Velázquez wrote: > That's my understanding: Environment variables must have values > (even empty ones), so unset shell variables cannot be placed into > the environment. One might propose that a valueless environment > variable could be represented as "name", but the standard requires > that environment strings contain a "=". And yet: > The shell shall give the export attribute to the variables > corresponding to the specified names, which shall cause them to be > in the environment of subsequently executed commands. would IMO mean that export attribute alone decides whether it's exported or not - not whether it has a set value. Unless set -u is given an expanded unset shell variable would give the empty string, so one could say that the similar concept would apply when the shell exports a variable that has the export attribute but no set value. Maybe I should open a ticket at austinbugs, asking for clarification. Perhaps also for the issue that Harald pointed out in his mail (about set -a + readonly). Cheers, Chris.
On Wed, 2024-02-28 at 00:56 +0000, Harald van Dijk wrote:
> However, trying to fix this I come across a corner case where it is
> not
> clear to me what the intended behaviour is.
>
> set -a; readonly foo=bar; export # some shells export, not all
As far as I can see, POSIX doesn't seem to be absolutely definite about
this, but personally I'd say the spirit of it is rather that set -a
generally applies, and so foo would be exported.
One might also argue like this:
* -a says "the export attribute shall be set for each variable to which
an assignment is performed".
* readonly does assign at some point before it returns and at that
point, the variable obviously cannot be readonly already.
Only before it returns it's made readonly.
Since -a acts already at the assignment step, it the export is set
before the readonly.
But of course, that's also a lot of reading something into it ;-)
Cheers,
Chris.
On 27/02/2024 02:07, Christoph Anton Mitterer wrote:
> Hey.
>
> Forwarding this from my report (for the records) at:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064874
>
>
> POSIX describes[0] unset to:
>> unset values and attributes of variables and functions
>
> While the exact detials are perhaps a bit unclear (see the discussion
> at [1], I
> think it is rather clear that unset, on a variable that has no readonly
> attribute,
> shall case the variable/value binding AND any attributes to be unset.
There is even a related bug where it causes attributes to be *added*:
under 'set -a', unset causes variables to be exported even if they
previously weren't.
set -a; unset foo; export
This is clearly wrong.
However, trying to fix this I come across a corner case where it is not
clear to me what the intended behaviour is.
set -a; readonly foo=bar; export # some shells export, not all
Cheers,
Harald van Dijk
On 27/02/2024 03:28, Christoph Anton Mitterer wrote:
> On Tue, 2024-02-27 at 03:07 +0000, Harald van Dijk wrote:
>> I suspect the reason you don't see it happen with TERM, LINENO, and
>> HISTSIZE is because you have built dash in a configuration in which
>> these variables are not special.
>
> Ah, I see... well I merely took the Debian unstable version of it.
>
>
>> For special variables, we get to
>>
>> flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
>>
>> where we preserve the VEXPORT of the previous value. In case of
>> VUNSET,
>> we should not be doing that. I agree with your expectations, unset
>> should clear the export attribute.
>
> So is it really just:
> --- a/src/var.c 2024-02-27 04:25:32.000000000 +0100
> +++ b/src/var.c 2024-02-27 04:22:40.744456151 +0100
> @@ -295,7 +295,7 @@
> goto out;
> }
>
> - flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
> + flags |= vp->flags & ~(VEXPORT|VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
> } else {
> if (flags & VNOSET)
> goto out;
>
> I had even had that before, and it seemed to work, but wasn't really
> sure whether it doesn't mess anything up behind the scenes which I
> didn't understand.
This isn't right, this will unexport variables in other cases.
export FOO; FOO=bar; export
Cheers,
Harald van Dijk
On Tue, Feb 27, 2024, at 12:11 AM, Christoph Anton Mitterer wrote:
> OTOH, 8.1 Environment Variable Definition says:
>> The array is pointed to by the external variable environ, which is
>> defined as:
>> extern char **environ;
>> These strings have the form name=value;
>
> So one might argue, that env vars must have some =value, and that this
> couldn't be done for exported shell vars with no (not even the empty)
> value.
That's my understanding: Environment variables must have values
(even empty ones), so unset shell variables cannot be placed into
the environment. One might propose that a valueless environment
variable could be represented as "name", but the standard requires
that environment strings contain a "=".
--
vq
subscribe
On Mon, 2024-02-26 at 23:23 -0500, Lawrence Velázquez wrote: > They are not exported. > > % env -i /opt/local/bin/dash > $ export MAIL=v > $ unset -v MAIL > $ export > export MAIL > export PWD='/private/tmp' > $ env > PWD=/private/tmp > > Their local counterparts are not exported, either. > > % env -i /opt/local/bin/dash > $ f() { local FOO=v; export FOO; unset -v FOO; export; env; > } > $ f > export FOO > export PWD='/private/tmp' > PWD=/private/tmp Interesting. I guess it simply doesn't export any vars for which no value is set (i.e. not even the empty value)?! Is that POSIXly correct? Even draft 4.1 says only: > The shell shall give the export attribute to the variables > corresponding to the specified names, which shall cause them to be > in the environment of subsequently executed commands. at the description of export. It doesn't say that variables with just the attribute should not be exported. OTOH, 8.1 Environment Variable Definition says: > The array is pointed to by the external variable environ, which is > defined as: > extern char **environ; > These strings have the form name=value; So one might argue, that env vars must have some =value, and that this couldn't be done for exported shell vars with no (not even the empty) value. It does seem to export a local exported var, if it has some value. Cheers, Chris.
On Mon, Feb 26, 2024, at 9:07 PM, Christoph Anton Mitterer wrote:
> The consequence of that is at least, that one has no chance to fully
> unset these variables and even if they loose their value, they’ll be
> exported to executed commands, possibly altering their behaviour.
They are not exported.
% env -i /opt/local/bin/dash
$ export MAIL=v
$ unset -v MAIL
$ export
export MAIL
export PWD='/private/tmp'
$ env
PWD=/private/tmp
Their local counterparts are not exported, either.
% env -i /opt/local/bin/dash
$ f() { local FOO=v; export FOO; unset -v FOO; export; env; }
$ f
export FOO
export PWD='/private/tmp'
PWD=/private/tmp
--
vq
On Tue, 2024-02-27 at 03:07 +0000, Harald van Dijk wrote: > I suspect the reason you don't see it happen with TERM, LINENO, and > HISTSIZE is because you have built dash in a configuration in which > these variables are not special. Ah, I see... well I merely took the Debian unstable version of it. > For special variables, we get to > > flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET); > > where we preserve the VEXPORT of the previous value. In case of > VUNSET, > we should not be doing that. I agree with your expectations, unset > should clear the export attribute. So is it really just: --- a/src/var.c 2024-02-27 04:25:32.000000000 +0100 +++ b/src/var.c 2024-02-27 04:22:40.744456151 +0100 @@ -295,7 +295,7 @@ goto out; } - flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET); + flags |= vp->flags & ~(VEXPORT|VTEXTFIXED|VSTACK|VNOSAVE|VUNSET); } else { if (flags & VNOSET) goto out; I had even had that before, and it seemed to work, but wasn't really sure whether it doesn't mess anything up behind the scenes which I didn't understand. If so, are you going to send a proper - or shall I? Thanks, Chris.
On 27/02/2024 02:07, Christoph Anton Mitterer wrote:
> This works as expected in dash for most variables, but not some, e.g.:
> $ env -i dash
> $ export
> export PWD='/home/calestyo'
> $ export MAIL
> $ export
> export MAIL
> export PWD='/home/calestyo'
> $ unset -v MAIL
> $ export
> export MAIL
> export PWD='/home/calestyo'
> $
>
> Same for MAILPATH and PATH, which made me believe it's perhaps an issue
> in `changemail` and `changepath` as given in the struct `varinit` in
> src/var.c.
> But it also happens with IFS, PS1, PS2 and PS4, which have no function
> listed there.
> OTOH, it doesn’t happen with ATTY, TERM, LINENO and HISTSIZE.
I suspect the reason you don't see it happen with TERM, LINENO, and
HISTSIZE is because you have built dash in a configuration in which
these variables are not special. I do see it happen with all three of
these. ATTY is dead code and is never special.
It looks like it is an incorrect handling of VSTRFIXED in setvareq().
The block
if (((flags & (VEXPORT|VREADONLY|VSTRFIXED|VUNSET)) |
(vp->flags & VSTRFIXED)) == VUNSET) {
should not be entered, and is not, but this is the block that makes it
work for normal variables. For special variables, we get to
flags |= vp->flags & ~(VTEXTFIXED|VSTACK|VNOSAVE|VUNSET);
where we preserve the VEXPORT of the previous value. In case of VUNSET,
we should not be doing that. I agree with your expectations, unset
should clear the export attribute.
VSTRFIXED is also used for local variables, so this explains what you
see there too.
Cheers,
Harald van Dijk
Hey. Forwarding this from my report (for the records) at: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064874 POSIX describes[0] unset to: > unset values and attributes of variables and functions While the exact detials are perhaps a bit unclear (see the discussion at [1], I think it is rather clear that unset, on a variable that has no readonly attribute, shall case the variable/value binding AND any attributes to be unset. This works as expected in dash for most variables, but not some, e.g.: $ env -i dash $ export export PWD='/home/calestyo' $ export MAIL $ export export MAIL export PWD='/home/calestyo' $ unset -v MAIL $ export export MAIL export PWD='/home/calestyo' $ Same for MAILPATH and PATH, which made me believe it's perhaps an issue in `changemail` and `changepath` as given in the struct `varinit` in src/var.c. But it also happens with IFS, PS1, PS2 and PS4, which have no function listed there. OTOH, it doesn’t happen with ATTY, TERM, LINENO and HISTSIZE. The consequence of that is at least, that one has no chance to fully unset these variables, and even if they loose their value, they’ll be exported to executed commands, possibly altering their behaviour. I think a similar problem exists when using local variables, but there it's even worse as it seems to affect any variable names: ``` f() { export echo local FOO=v export FOO export echo unset -v FOO export } f ``` gives: ``` export PWD='/home/calestyo' export FOO='v' export PWD='/home/calestyo' export FOO export PWD='/home/calestyo' ``` and presumaby that `FOO` would then be exported to executed commands. Cheers, Chris. [0] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#unset [1] https://austingroupbugs.net/view.php?id=1806
Hi,
On 16/02/2024 16:33, Fabrice Fontaine wrote:
> Drop -Wl,--fatal-warnings with --enable-static to avoid the following
> static build failure:
>
> configure:4778: checking for strtod
> configure:4778: /home/autobuild/autobuild/instance-8/output-1/host/bin/powerpc-buildroot-linux-uclibcspe-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mabi=spe -mfloat-gprs=single -Wa,-me500 -Os -g0 -static -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -static -Wl,--fatal-warnings conftest.c >&5
> /home/autobuild/autobuild/instance-8/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibcspe/8.4.0/../../../../powerpc-buildroot-linux-uclibcspe/bin/ld: warning: conftest has a LOAD segment with RWX permissions
> collect2: error: ld returned 1 exit status
Where is this warning coming from? Does it show a real problem that
needs to be addressed?
As for the actual patch, you're right that configure should not be using
-Wl,--fatal-warnings, it should be avoided there for the same reason
-Werror should be, the warnings that get promoted to errors differ
between toolchain versions and in general, it is not possible to ensure
that all valid toolchains, all valid warning flags, result in no warnings.
I suspect though that it was added for a reason, that there were things
that *should* cause configure checks to fail, that did not fail except
with -Wl,--fatal-warnings. Whatever that reason may have been, it will
need to be handled differently if -Wl,--fatal-warnings is dropped.
Unfortunately, it was added to dash back in 2007 before the current
mailing list existed, so I am having trouble finding any explanation for
what those errors may have been.
Dropping it sounds good to me if no one can tell why it is there, but I
would suggest some experimentation may be in order to try and figure
that out first.
Cheers,
Harald van Dijk
Drop -Wl,--fatal-warnings with --enable-static to avoid the following static build failure: configure:4778: checking for strtod configure:4778: /home/autobuild/autobuild/instance-8/output-1/host/bin/powerpc-buildroot-linux-uclibcspe-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -mabi=spe -mfloat-gprs=single -Wa,-me500 -Os -g0 -static -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -static -Wl,--fatal-warnings conftest.c >&5 /home/autobuild/autobuild/instance-8/output-1/host/lib/gcc/powerpc-buildroot-linux-uclibcspe/8.4.0/../../../../powerpc-buildroot-linux-uclibcspe/bin/ld: warning: conftest has a LOAD segment with RWX permissions collect2: error: ld returned 1 exit status [...] In file included from arith_yylex.c:44: system.h:74:22: error: static declaration of 'strtod' follows non-static declaration static inline double strtod(const char *nptr, char **endptr) ^~~~~~ Fixes: - http://autobuild.buildroot.org/results/a54fdc7d1b94beb47203373ae35b08d9cea8d42c Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5524650..6993364 100644 --- a/configure.ac +++ b/configure.ac @@ -34,7 +34,7 @@ fi AC_ARG_ENABLE(static, AS_HELP_STRING(--enable-static, \ [Build statical linked program])) if test "$enable_static" = "yes"; then - export LDFLAGS="-static -Wl,--fatal-warnings" + export LDFLAGS="-static" fi AC_ARG_ENABLE(fnmatch, AS_HELP_STRING(--disable-fnmatch, \ -- 2.43.0
On Wed, Feb 7, 2024, at 11:04 PM, Oliver Webb wrote: > Thanks, although the correct address appears to now be > "dash+subscribe@vger.kernel.org", > since majordomo commands aren't supported anymore Ah, I suppose that has something to do with the vger migration last October. The homepage (<http://gondor.apana.org.au/~herbert/dash/>) should be updated then. -- vq
On Wednesday, February 7th, 2024 at 21:46, Lawrence Velázquez <vq@larryv.me> wrote: > On Wed, Feb 7, 2024, at 10:34 PM, Oliver Webb wrote: > > > subscribe dash > > > To subscribe, resend this message to majordomo@vger.kernel.org. Thanks, although the correct address appears to now be "dash+subscribe@vger.kernel.org", since majordomo commands aren't supported anymore > -- > vq - Oliver Webb <aquahobbyist@proton.me>