"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-requ...@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-requ...@gnu.org > > You can reach the person managing the list at > bug-bash-ow...@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.ra...@case.edu> > To: bug-bash@gnu.org > Cc: chet.ra...@case.edu > Subject: Re: redirection / process substitution fails to read a file > descriptor > Message-ID: <ddf798fc-beb7-4c70-8e0e-71b4a3b64...@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 c...@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 <grishale...@gmail.com> > To: chet.ra...@case.edu > Cc: bug-bash <bug-bash@gnu.org> > Subject: Re: history-search-* and undo lists > Message-ID: > <CAMu=BrqMmhYLJx40pkyOUkG_= > kqjrnqjb03c-wb-0dbrnnu...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Tue, Nov 5, 2024 at 11:20 AM Chet Ramey <chet.ra...@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 <grishale...@gmail.com> > To: chet.ra...@case.edu > Cc: bug-bash@gnu.org > Subject: Re: [PATCH] lib/readline/doc makefiles clean targets > Message-ID: > <CAMu= > brrupqq9wh-2_xfrgrcdvphdsn8poea1obymhoskupy...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Wed, Nov 13, 2024 at 11:13 AM Chet Ramey <chet.ra...@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.nore...@gnu.org> > To: chet.ra...@case.edu, bug-bash@gnu.org > Subject: [bug #66460] A documentation correction regarding an array > nameref??? > Message-ID: <20241119-064006.sv343488.282...@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.kah...@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 > ***************************************** >
