Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

[Chet Ramey]

On 2/13/24 12:41 PM, Grisha Levit wrote:
On Wed, Jan 31, 2024, 14:10 Chet Ramey > wrote:


Well, is this a "my arm hurts when I do this" problem, or should bash
restrict the types of attributes that can be set on readonly variables?


For the attributes that only affect future assignments ([iluc]), I think 
think it makes sense to either (a) restrict the ability to change these 
attributes on readonly variables or (b) make internal assignments that 
force new values on readonly variables ignore such attributes.


Let's say we take the approach of restricting attribute changes on readonly
variables to export/trace/local.

Should it be an error to attempt to set other attributes (it already is
with nameref), or should declare silently ignore it?

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

[Grisha Levit]

On Fri, Feb 16, 2024 at 11:32 AM Chet Ramey  wrote:
>
> On 2/13/24 12:41 PM, Grisha Levit wrote:
> > On Wed, Jan 31, 2024, 14:10 Chet Ramey  > > wrote:
> >
> > Well, is this a "my arm hurts when I do this" problem, or should bash
> > restrict the types of attributes that can be set on readonly variables?
> >
> > For the attributes that only affect future assignments ([iluc]), I think
> > think it makes sense to either (a) restrict the ability to change these
> > attributes on readonly variables or (b) make internal assignments that
> > force new values on readonly variables ignore such attributes.
>
> Let's say we take the approach of restricting attribute changes on readonly
> variables to export/trace/local.
>
> Should it be an error to attempt to set other attributes (it already is
> with nameref), or should declare silently ignore it?


I think an error (probably just the usual sh_readonly one) would be good.

Re: It is possible to remove the readonly attribute from {BASH, SHELL}OPTS

[Chet Ramey]

On 2/16/24 12:14 PM, Grisha Levit wrote:


Let's say we take the approach of restricting attribute changes on readonly
variables to export/trace/local.

Should it be an error to attempt to set other attributes (it already is
with nameref), or should declare silently ignore it?



I think an error (probably just the usual sh_readonly one) would be good.


I agree.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Bash 5.1: Make shell_script_filename available to startup files

[Marc Aurèle La France]

On Mon, 2021-Feb-01, Marc Aurèle La France wrote:


Currently, only the script's arguments are passed as positional
parameters.  For compatibility reasons, $0 cannot be used to also pass the
script's filename, so I'm creating a new BASH_SCRIPT variable instead.



--- bash-5.1/doc/bash.1
+++ devel-5.1/doc/bash.1
@@ -1610,6 +1610,11 @@ matching the entire regular expression.
The element with index \fIn\fP is the portion of the
string matching the \fIn\fPth parenthesized subexpression.
.TP
+.B BASH_SCRIPT
+The name of the script currently being executed by \fBbash\fP, as specified on
+the command line.
+This is set before any startup files are executed for the script.
+.TP
.B BASH_SOURCE
An array variable whose members are the source filenames
where the corresponding shell function names in the
--- bash-5.1/doc/bashref.texi
+++ devel-5.1/doc/bashref.texi
@@ -5810,6 +5810,11 @@ matching the entire regular expression.
The element with index @var{n} is the portion of the
string matching the @var{n}th parenthesized subexpression.

+@item BASH_SCRIPT
+The name of the script currently being executed by bash, as specified on
+the command line.  This is set before any startup files are executed for
+the script.
+
@item BASH_SOURCE
An array variable whose members are the source filenames where the
corresponding shell function names in the @code{FUNCNAME} array
--- bash-5.1/shell.c
+++ devel-5.1/shell.c
@@ -686,6 +686,7 @@ main (argc, argv, env)
  else if (arg_index != argc && read_from_stdin == 0)
{
  shell_script_filename = argv[arg_index++];
+  bind_variable ("BASH_SCRIPT", shell_script_filename, 0);
  arg_index = bind_args (argv, arg_index, argc, 1); /* $1 ... $n */
}
  else



Yes, it's been three years, but...

Withdrawn.  I can accomplish the same thing by capturing $_ early on, 
before it gets clobbered by whatever.


Marc.

Re: Bash 5.1: Make shell_script_filename available to startup files

[Zachary Santer]

On Fri, Feb 16, 2024 at 4:17 PM Marc Aurèle La France 
wrote:

> On Mon, 2021-Feb-01, Marc Aurèle La France wrote:
>
> > Currently, only the script's arguments are passed as positional
> > parameters.  For compatibility reasons, $0 cannot be used to also pass
> the
> > script's filename, so I'm creating a new BASH_SCRIPT variable instead.
>

And you're sure ${BASH_SOURCE[0]} wasn't what you wanted all along?

$* within a here-document puts space instead of the first IFS char.

[Damien ISSANCHOU]

From: Damien Issanchou
To: bug-bash@gnu.org
Subject: $* within a here-document puts space instead of the first IFS char.

Configuration Information:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
uname output: Linux AsWhite 4.19.0-20-amd64 #1 SMP Debian 4.19.235-1 
(2022-03-17) x86_64 GNU/Linux

Machine Type: x86_64-pc-linux-gnu

Bash Version: 5.2
Patch Level: 26
Release Status: release

Description:
    Hi,

    When expanding $* within a here-document, bash puts a space between 
each positional parameters while I would expect it to put the first 
character of the IFS variable (if it contains at least one character) as 
per POSIX.1-2017.


    Even though the online Bash Reference manual only explicitly states 
the POSIX behaviour when the expansion of the special parameter * occurs 
within double-quotes, it seems that it is also implemented in other 
contexts where field splitting shall not be performed such as within 
here strings.


    Funnily enough, the expansion of ${array[*]} does make use of the 
first IFS character within a here document, making it behave more 
POSIX.1-ly that $*.


    Maybe bash could implement the POSIX.1 behaviour for $* within 
here-documents, which would make the * special parameter and the * 
"special" array subscript much more look-alike.


    Best Regards,

    Damien


Repeat-By:

    IFS=xyz
    set -- a b c
    cat <    The following change seems to implement the desired behaviour, by 
treating the expansion of $* no differently within a here-document that 
within double quotes.


    diff -r -U 7 bash-master.orig/subst.c bash-master/subst.c
    --- bash-master.orig/subst.c    2024-01-14 00:27:28.0 +0100
    +++ bash-master/subst.c    2024-02-16 23:43:37.243819094 +0100
    @@ -10358,15 +10358,15 @@
       else if (quoted & (Q_HERE_DOCUMENT|Q_DOUBLE_QUOTES|Q_PATQUOTE))
         {
           /* If we have "$*" we want to make a string of the positional
          parameters, separated by the first character of $IFS, and
          quote the whole string, including the separators. If IFS
          is unset, the parameters are separated by ' '; if $IFS is
          null, the parameters are concatenated. */
    -      temp = (quoted & (Q_DOUBLE_QUOTES|Q_PATQUOTE)) ? 
string_list_dollar_star (list, quoted, 0) : string_list (list);

    +      temp = string_list_dollar_star (list, quoted, 0);
           if (temp)
             {
           temp1 = (quoted & Q_DOUBLE_QUOTES) ? quote_string (temp) 
: temp;

           if (*temp == 0)
             tflag |= W_HASQUOTEDNULL;
           if (temp != temp1)
             free (temp);

Re: [PATCH] use unlocked stdio functions

[Grisha Levit]

After this change, `make -C examples/loadables others` fails building
necho.o with:

use of undeclared identifier 'fflush_unlocked'

I checked other object files to make sure the expected symbols are used
and they were, except for the loadable pushd.

Also added the dependency where needed in Makefile.in -- do you usually
do these manually or with some tool?

* builtins/pushd.def,examples/loadables/necho.c
- fix include order for unlocked-io
* Makefile.in
- BASHINCFILES,INSTALLED_INCFILES: add missing header files
- $(BASHINCDIR)/unlocked-io.h: add to relevant .o deps
---
 Makefile.in| 58 --
 builtins/pushd.def |  7 ++---
 examples/loadables/necho.c |  2 +-
 3 files changed, 35 insertions(+), 32 deletions(-)

diff --git a/Makefile.in b/Makefile.in
index 2f863e86..c621cafc 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -438,7 +438,11 @@ BASHINCFILES =  $(BASHINCDIR)/posixstat.h 
$(BASHINCDIR)/ansi_stdlib.h \
 $(BASHINCDIR)/posixtime.h $(BASHINCDIR)/systimes.h \
 $(BASHINCDIR)/unionwait.h $(BASHINCDIR)/maxpath.h \
 $(BASHINCDIR)/shtty.h $(BASHINCDIR)/typemax.h \
-$(BASHINCDIR)/ocache.h
+$(BASHINCDIR)/ocache.h $(BASHINCDIR)/chartypes.h \
+$(BASHINCDIR)/gettext.h $(BASHINCDIR)/posixselect.h \
+$(BASHINCDIR)/shmbchar.h $(BASHINCDIR)/shmbutil.h \
+$(BASHINCDIR)/stat-time.h $(BASHINCDIR)/timer.h \
+$(BASHINCDIR)/unlocked-io.h
 
 LIBRARIES = $(GLOB_LIB) $(SHLIB_LIB) $(READLINE_LIB) $(HISTORY_LIB) \
$(TERMCAP_LIB) $(TILDE_LIB) $(MALLOC_LIB) $(INTL_LIB) $(LIBICONV) \
@@ -487,7 +491,7 @@ INSTALLED_BUILTINS_HEADERS = bashgetopt.h common.h getopt.h
 INSTALLED_INCFILES =posixstat.h ansi_stdlib.h filecntl.h posixdir.h \
memalloc.h stdc.h posixjmp.h posixwait.h posixtime.h systimes.h \
unionwait.h maxpath.h shtty.h typemax.h ocache.h chartypes.h gettext.h \
-   posixstat.h shmbchar.h shmbutil.h stat-time.h
+   shmbchar.h shmbutil.h stat-time.h posixselect.h timer.h unlocked-io.h
 
 # header files chosen based on running of configure
 SIGNAMES_H = @SIGNAMES_H@
@@ -1076,13 +1080,13 @@ error.o: general.h xmalloc.h bashtypes.h variables.h 
arrayfunc.h conftypes.h arr
 error.o: quit.h ${BASHINCDIR}/maxpath.h unwind_prot.h dispose_cmd.h
 error.o: make_cmd.h subst.h sig.h pathnames.h externs.h execute_cmd.h
 error.o: input.h execute_cmd.h 
-error.o: $(BASHINCDIR)/ocache.h $(BASHINCDIR)/chartypes.h assoc.h
+error.o: $(BASHINCDIR)/ocache.h $(BASHINCDIR)/chartypes.h assoc.h 
$(BASHINCDIR)/unlocked-io.h
 eval.o: config.h bashansi.h ${BASHINCDIR}/ansi_stdlib.h trap.h flags.h 
${DEFSRC}/common.h
 eval.o: shell.h syntax.h config.h bashjmp.h ${BASHINCDIR}/posixjmp.h command.h 
${BASHINCDIR}/stdc.h error.h
 eval.o: general.h xmalloc.h bashtypes.h variables.h arrayfunc.h conftypes.h 
array.h hashlib.h
 eval.o: quit.h ${BASHINCDIR}/maxpath.h unwind_prot.h dispose_cmd.h
 eval.o: make_cmd.h subst.h sig.h pathnames.h externs.h parser.h
-eval.o: input.h execute_cmd.h 
+eval.o: input.h execute_cmd.h $(BASHINCDIR)/unlocked-io.h
 eval.o: bashhist.h assoc.h ${BASHINCDIR}/ocache.h ${BASHINCDIR}/chartypes.h
 execute_cmd.o: config.h bashtypes.h ${BASHINCDIR}/filecntl.h 
${BASHINCDIR}/posixstat.h bashansi.h ${BASHINCDIR}/ansi_stdlib.h
 execute_cmd.o: shell.h syntax.h config.h bashjmp.h ${BASHINCDIR}/posixjmp.h 
command.h ${BASHINCDIR}/stdc.h error.h
@@ -1093,7 +1097,7 @@ execute_cmd.o: ${BASHINCDIR}/memalloc.h ${GRAM_H} flags.h 
builtins.h jobs.h quit
 execute_cmd.o: execute_cmd.h findcmd.h redir.h trap.h test.h pathexp.h
 execute_cmd.o: $(DEFSRC)/common.h ${DEFDIR}/builtext.h 
${GLOB_LIBSRC}/strmatch.h
 execute_cmd.o: ${BASHINCDIR}/posixtime.h ${BASHINCDIR}/chartypes.h
-execute_cmd.o: $(DEFSRC)/getopt.h
+execute_cmd.o: $(DEFSRC)/getopt.h $(BASHINCDIR)/unlocked-io.h
 execute_cmd.o: bashhist.h input.h ${GRAM_H} assoc.h hashcmd.h alias.h
 execute_cmd.o: ${BASHINCDIR}/ocache.h ${BASHINCDIR}/posixwait.h
 expr.o: config.h bashansi.h ${BASHINCDIR}/ansi_stdlib.h 
@@ -1152,7 +1156,7 @@ locale.o: make_cmd.h subst.h sig.h pathnames.h externs.h
 locale.o: ${BASHINCDIR}/chartypes.h
 locale.o: input.h assoc.h ${BASHINCDIR}/ocache.h
 mailcheck.o: config.h bashtypes.h ${BASHINCDIR}/posixstat.h bashansi.h 
${BASHINCDIR}/ansi_stdlib.h
-mailcheck.o: ${BASHINCDIR}/posixtime.h
+mailcheck.o: ${BASHINCDIR}/posixtime.h $(BASHINCDIR)/unlocked-io.h
 mailcheck.o: shell.h syntax.h config.h bashjmp.h ${BASHINCDIR}/posixjmp.h 
command.h ${BASHINCDIR}/stdc.h error.h
 mailcheck.o: general.h xmalloc.h bashtypes.h variables.h arrayfunc.h 
conftypes.h array.h hashlib.h
 mailcheck.o: quit.h ${BASHINCDIR}/maxpath.h unwind_prot.h dispose_cmd.h
@@ -1174,7 +1178,7 @@ y.tab.o: quit.h ${BASHINCDIR}/maxpath.h unwind_prot.h 
dispose_cmd.h
 y.tab.o: make_cmd.h subst.h sig.h pathnames.h externs.h test.h execute_cmd.o
 y.tab.o: trap.h flags.h parser.

Re: Bash 5.1: Make shell_script_filename available to startup files

[Marc Aurèle La France]

On Fri, 2024-Feb-16, Zachary Santer wrote:

On Fri, Feb 16, 2024, Marc Aurèle La France wrote:

On Mon, 2021-Feb-01, Marc Aurèle La France wrote:



Currently, only the script's arguments are passed as positional
parameters.  For compatibility reasons, $0 cannot be used to also pass
the script's filename, so I'm creating a new BASH_SCRIPT variable
instead.



And you're sure ${BASH_SOURCE[0]} wasn't what you wanted all along?


Yes, but that doesn't matter now.

Marc.

Re: $* within a here-document puts space instead of the first IFS char.

[Robert Elz]

Date:Sat, 17 Feb 2024 01:41:11 +0100
From:Damien ISSANCHOU 
Message-ID:  

  | Even though the online Bash Reference manual only explicitly states 
  | the POSIX behaviour when the expansion of the special parameter * occurs 
  | within double-quotes, it seems that it is also implemented in other 
  | contexts where field splitting shall not be performed such as within 
  | here strings.

Note that a here doc without a quoted end word (after <<) is essentially
a double quoted string - apart from the " character being nothing special
in it, it shoud be treated exactly as a double quoted string would be.

(If the end word were quoted, then the here doc would be a single
quoted string - except without ' meaning anything - which is a very
boring case.)

The leading tab removal that happens with <<- is a separate issue,
that happens when the here doc is being read, rather than when it
is being expanded (when it is used.)

  |      Maybe bash could implement the POSIX.1 behaviour for $* within 
  | here-documents, which would make the * special parameter and the * 
  | "special" array subscript much more look-alike.

It certainly should.

How the implementation makes this happen is its business, but there's
really just one $* expansion which can be used in all situations.
That is the positional params separated by the first char of $IFS
(with the usual rule for when that is empty or unset applying).

In the cases where the $* was unquoted, and in a context where
field splitting occurs, those IFS characters that were inserted
are all removed again by the field splitting algorithm, so sometimes
it appears as if that is a different expansion kind which doesn't
use IFS at all - and could be implemented that way, but there's
really no need, field splitting still needs to happen, in case
one of the positional params has an IFS char in it, and it can be
tricky to get that right if that char is first or last in the
positional param if the algorithm isn't fully implemented (including
actually splitting based upon the inserted IFS chars between the
positional params).

kre

Re: Bash 5.1: Make shell_script_filename available to startup files

[Grisha Levit]

On Fri, Feb 16, 2024, 16:17 Marc Aurèle La France  wrote:
>
> On Mon, 2021-Feb-01, Marc Aurèle La France wrote:
>
> > Currently, only the script's arguments are passed as positional
> > parameters.  For compatibility reasons, $0 cannot be used to also pass the
> > script's filename, so I'm creating a new BASH_SCRIPT variable instead.
>
> > --- bash-5.1/doc/bash.1
> > +++ devel-5.1/doc/bash.1

> Yes, it's been three years, but...
>
> Withdrawn.  I can accomplish the same thing by capturing $_ early on,
> before it gets clobbered by whatever.

I believe bash-5.2 and up do behave the way you want w.r.t. the value
of $0 when running the BASH_ENV script.

See https://git.savannah.gnu.org/cgit/bash.git/tree/NEWS-5.2?h=devel#n58 :

p. The `$0' special parameter is now set to the name of the script when running
   any (non-interactive) startup files such as $BASH_ENV.

Re: $* within a here-document puts space instead of the first IFS char.

[Grisha Levit]

On Fri, Feb 16, 2024 at 9:02 PM Damien ISSANCHOU  wrote:
>  When expanding $* within a here-document, bash puts a space between
> each positional parameters while I would expect it to put the first
> character of the IFS variable (if it contains at least one character) as
> per POSIX.1-2017.

FYI, this seems to be the same issue as reported in
https://lists.gnu.org/archive/html/bug-bash/2022-09/msg2.html

And the devel branch has exactly the fix the you propose:
https://git.savannah.gnu.org/cgit/bash.git/tree/subst.c?h=devel&id=e1dd98a1d#n10513