[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug #66460] A documentation correction regarding an array nameref??
|
From: |
Wiley Young |
|
Subject: |
Re: [bug #66460] A documentation correction regarding an array nameref??? |
|
Date: |
Wed, 20 Nov 2024 01:48:04 -0800 |
"The nameref attribute cannot be applied to array variables."
Some thoughts on English language
Perhaps "attribute" could be more explicitly defined? ...as something
like, 'a characteristic [ given to | assigned to | applied to | associated
with | defining a ] parameter (or a parameter's utility?)'
Active voicing could describe the relationship between parameters and
attributes a little more accurately. Something like, 'parameters can
receive attribute designations....' 'Attributes can [ limit | define ] the
[ functionality | use ] of a parameter....'
Or possibly it's just something to do with how the various attributes as
a group interact? 'Some attributes are mutually exclusive: a parameter
marked as an array cannot also [ be marked as a | receive the ] namref
(attribute), etc...'
2 cents,
Wiley
On Mon, Nov 18, 2024, 23:10 <bug-bash-request@gnu.org> wrote:
> Send bug-bash mailing list submissions to
> bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a message with subject or body 'help' to
> bug-bash-request@gnu.org
>
> You can reach the person managing the list at
> bug-bash-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-bash digest..."
>
>
> Today's Topics:
>
> 1. Re: redirection / process substitution fails to read a file
> descriptor (Chet Ramey)
> 2. Re: history-search-* and undo lists (Grisha Levit)
> 3. Re: [PATCH] lib/readline/doc makefiles clean targets
> (Grisha Levit)
> 4. [bug #66460] A documentation correction regarding an array
> nameref??? (Harry Clauson)
> 5. Re: [bug #66460] A documentation correction regarding an
> array nameref??? (Andreas Kähäri)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 18 Nov 2024 16:04:51 -0500
> From: Chet Ramey <chet.ramey@case.edu>
> To: bug-bash@gnu.org
> Cc: chet.ramey@case.edu
> Subject: Re: redirection / process substitution fails to read a file
> descriptor
> Message-ID: <ddf798fc-beb7-4c70-8e0e-71b4a3b6461e@case.edu>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 11/17/24 6:25 PM, Robert Elz wrote:
>
> > The use for testing for errors is also occasionally useful - a
> redirection
> > error will cause the shell to exit (non-interactive shell) so <file can
> > be a kind of shortcut for
> > test -r file || { printf >&2 message; exit 2; }
> > (or similar) (and output directions test that the file either exists or
> > can be created, and is writeable).
>
> No, it usually doesn't. If a redirection error occurs with a special
> builtin, POSIX says a non-interactive shell should exit. However,
> just running
>
> < file
>
> where file doesn't exist or isn't readable, won't cause a non-interactive
> shell to exit.
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU chet@case.edu http://tiswww.cwru.edu/~chet/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: OpenPGP_signature.asc
> Type: application/pgp-signature
> Size: 203 bytes
> Desc: OpenPGP digital signature
> URL: <
> https://lists.gnu.org/archive/html/bug-bash/attachments/20241118/0d31cfb6/attachment.sig
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 18 Nov 2024 22:22:10 -0500
> From: Grisha Levit <grishalevit@gmail.com>
> To: chet.ramey@case.edu
> Cc: bug-bash <bug-bash@gnu.org>
> Subject: Re: history-search-* and undo lists
> Message-ID:
> <CAMu=BrqMmhYLJx40pkyOUkG_=
> kQJrnqJB03c-WB-0DbRNnUPsg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Tue, Nov 5, 2024 at 11:20 AM Chet Ramey <chet.ramey@case.edu> wrote:
> >
> > On 10/18/24 4:22 PM, Grisha Levit wrote:
> > > There's some issue with undo list handling in history-search-*
> commands:
> > >
> > > Doing a successful search with a line that has an undo list causes the
> > > undo entries from that list to leaked:
> >
> > Thanks for the report. Please try this with the latest devel branch push.
>
> Yup, can confirm much fewer fuzzing hits now.
>
> But here's a remaining one in combination with history-expand-line:
>
> HISTFILE= INPUTRC=/ bash --norc -in <<< \
> $'X\n\e[A!X\e^\e[A'
> =================================================================
> ERROR: LeakSanitizer: detected memory leaks
>
> Direct leak of 32 byte(s) in 1 object(s) allocated from:
> #2 alloc_undo_entry lib/readline/undo.c:75:23
> #3 rl_add_undo lib/readline/undo.c:92:10
> #4 maybe_make_readline_line bashline.c:2804:7
> #5 set_up_new_line bashline.c:2832:3
> #6 history_expand_line bashline.c:2896:7
> #7 _rl_dispatch_subseq lib/readline/readline.c:941:8
>
>
> HISTFILE= INPUTRC=/ bash --norc -in <<< \
> $'X\n\cPX\e[A!X\et\e^\exhistory-search-forward\n\e1\cO'
> =================================================================
> ERROR: AddressSanitizer: heap-use-after-free on address 0xe87234c21f48
> READ of size 4 at 0xe87234c21f48 thread T0
> #0 rl_do_undo undo.c:188:25
> #1 rl_revert_line undo.c:339:2
> #2 readline_common_teardown readline.c:493:7
> #3 readline_internal_teardown readline.c:518:3
> #4 readline_internal readline.c:750:11
> #5 readline readline.c:387:11
>
> 0xe87234c21f48 is located 24 bytes inside of 32-byte region
> [0xe87234c21f30,0xe87234c21f50)
> freed by thread T0 here:
> #2 _rl_free_undo_list undo.c:111:7
> #3 rl_free_undo_list undo.c:122:3
> #4 readline_common_teardown readline.c:507:5
> #5 readline_internal_teardown readline.c:518:3
> #6 readline_internal readline.c:750:11
> #7 readline readline.c:387:11
>
> previously allocated by thread T0 here:
> #2 alloc_undo_entry undo.c:75:23
> #3 rl_add_undo undo.c:92:10
> #4 rl_insert_text text.c:114:2
> #5 _rl_insert_char text.c:935:7
> #6 rl_insert text.c:989:42
> #7 _rl_dispatch_subseq readline.c:941:8
> #8 _rl_dispatch readline.c:876:10
> #9 readline_internal_char readline.c:690:11
> #10 readline_internal_charloop readline.c:737:11
> #11 readline_internal readline.c:749:18
> #12 readline readline.c:387:11
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 18 Nov 2024 22:28:38 -0500
> From: Grisha Levit <grishalevit@gmail.com>
> To: chet.ramey@case.edu
> Cc: bug-bash@gnu.org
> Subject: Re: [PATCH] lib/readline/doc makefiles clean targets
> Message-ID:
> <CAMu=
> BrrUpQq9Wh-2_XfRgRcdVpHDsn8POeA1ObymHOskUPyRAg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, Nov 13, 2024 at 11:13 AM Chet Ramey <chet.ramey@case.edu> wrote:
> >
> > On 11/12/24 7:18 PM, Grisha Levit wrote:
> >
> > > The latest change,
> > >
> > > +Makefile.in
> > > + - y.tab.h: move from CREATED_HEADERS to INSTALLED_HEADERS so we don't
> > > + clean it
> > >
> > > makes the install-headers target fail for an out-of-tree build since
> y.tab.h
> > > is in $(BUILD_DIR) but INSTALLED_HEADERS are only looked for in
> $(srcdir)
> >
> > This is one of the differences between the distributions and the devel
> > branch. y.tab.h is always in $(srcdir) in distributions, and the
> Makefiles
> > accommodate them in favor of the devel branch.
>
> Could we install INSTALLED_HEADERS the same way as CREATED_HEADERS are?
> i.e. installing from $(BUILD_DIR) if it exists there and from $(srcdir)
> if not?
>
>
>
> ------------------------------
>
> Message: 4
> Date: Tue, 19 Nov 2024 01:40:12 -0500 (EST)
> From: Harry Clauson <INVALID.NOREPLY@gnu.org>
> To: chet.ramey@case.edu, bug-bash@gnu.org
> Subject: [bug #66460] A documentation correction regarding an array
> nameref???
> Message-ID: <20241119-064006.sv343488.282319@savannah.gnu.org>
> Content-Type: text/plain; charset="utf-8"
>
> URL:
> <https://savannah.gnu.org/bugs/?66460>
>
> Summary: A documentation correction regarding an array
> nameref???
> Group: The GNU Bourne-Again SHell
> Submitter: harryc
> Submitted: Tue 19 Nov 2024 06:40:06 AM UTC
> Category: None
> Severity: 3 - Normal
> Item Group: None
> Status: None
> Privacy: Public
> Assigned to: None
> Open/Closed: Open
> Discussion Lock: Any
>
>
> _______________________________________________________
>
> Follow-up Comments:
>
>
> -------------------------------------------------------
> Date: Tue 19 Nov 2024 06:40:06 AM UTC By: Harry Clauson <harryc>
> I was surprised that the documentation for "declare -n" states:
>
> "The nameref attribute cannot be applied to array variables."
>
> This appears to be incorrect as I frequently pass arrays using a nameref to
> avoid the overhead of making a copy of large amounts of data.
>
> For example:
>
> ####################################################
> function doit {
> local -n blahref=$1
> echo ${blahref[2]} # displays z
> blahref[2]=a
> blahref[3]=b
> return 0
> }
>
> declare -a blah
> blah=(x y z)
>
> echo ${blah[2]} # displays z
>
> doit blah
> echo ${blah[2]} # displays a
> echo ${blah[3]} # displays b
> ####################################################
>
> In addition, when browsing the internet I see many questions regarding how
> to
> pass an array by reference, and the answers do not mention simply using a
> nameref. And if not using a nameref it appears that they are actually
> passing
> data by value which is inefficient, especially in the case of arrays.
>
> This leads me to believe that users who have read the documentation are not
> using this valuable feature, nor are they passing it along to others when
> answering related questions.
>
> Please let me know if I am missing something here or if the documentation
> should be corrected in this regard.
>
> Thank you!
>
>
>
>
>
>
>
>
>
> _______________________________________________________
>
> Reply to this item at:
>
> <https://savannah.gnu.org/bugs/?66460>
>
> _______________________________________________
> Message sent via Savannah
> https://savannah.gnu.org/
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 228 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/bug-bash/attachments/20241119/ab83afc2/attachment.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Tue, 19 Nov 2024 08:09:43 +0100
> From: Andreas Kähäri <andreas.kahari@abc.se>
> To: bug-bash@gnu.org
> Subject: Re: [bug #66460] A documentation correction regarding an
> array nameref???
> Message-ID: <Zzw5t_AJlw60PEDc@eeyore.invalid>
> Content-Type: text/plain; charset=utf-8
>
> On Tue, Nov 19, 2024 at 01:40:12AM -0500, Harry Clauson wrote:
> > URL:
> > <https://savannah.gnu.org/bugs/?66460>
> >
> > Summary: A documentation correction regarding an array
> > nameref???
> > Group: The GNU Bourne-Again SHell
> > Submitter: harryc
> > Submitted: Tue 19 Nov 2024 06:40:06 AM UTC
> > Category: None
> > Severity: 3 - Normal
> > Item Group: None
> > Status: None
> > Privacy: Public
> > Assigned to: None
> > Open/Closed: Open
> > Discussion Lock: Any
> >
> >
> > _______________________________________________________
> >
> > Follow-up Comments:
> >
> >
> > -------------------------------------------------------
> > Date: Tue 19 Nov 2024 06:40:06 AM UTC By: Harry Clauson <harryc>
> > I was surprised that the documentation for "declare -n" states:
> >
> > "The nameref attribute cannot be applied to array variables."
> >
> > This appears to be incorrect as I frequently pass arrays using a nameref
> to
> > avoid the overhead of making a copy of large amounts of data.
> >
> > For example:
> >
> > ####################################################
> > function doit {
> > local -n blahref=$1
> > echo ${blahref[2]} # displays z
> > blahref[2]=a
> > blahref[3]=b
> > return 0
> > }
> >
> > declare -a blah
> > blah=(x y z)
> >
> > echo ${blah[2]} # displays z
> >
> > doit blah
> > echo ${blah[2]} # displays a
> > echo ${blah[3]} # displays b
> > ####################################################
> >
>
> The code above does not apply the nameref attribute to an array.
>
> Applying the nameref attribute to an array would be doing this:
>
> $ declare -n ref[0]=a
> bash: declare: ref[0]: reference variable cannot be an array
>
>
> > In addition, when browsing the internet I see many questions regarding
> how to
> > pass an array by reference, and the answers do not mention simply using a
> > nameref. And if not using a nameref it appears that they are actually
> passing
> > data by value which is inefficient, especially in the case of arrays.
> >
> > This leads me to believe that users who have read the documentation are
> not
> > using this valuable feature, nor are they passing it along to others when
> > answering related questions.
> >
> > Please let me know if I am missing something here or if the documentation
> > should be corrected in this regard.
> >
> > Thank you!
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > _______________________________________________________
> >
> > Reply to this item at:
> >
> > <https://savannah.gnu.org/bugs/?66460>
> >
> > _______________________________________________
> > Message sent via Savannah
> > https://savannah.gnu.org/
>
>
>
> --
> Andreas (Kusalananda) Kähäri
> Uppsala, Sweden
>
> .
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bug-bash mailing list
> bug-bash@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-bash
>
>
> ------------------------------
>
> End of bug-bash Digest, Vol 264, Issue 37
> *****************************************
>