Re: [PATCH] Makefile.in: add LIBINTL_H to install-headers

[Martin D Kealey]

On Thu, 14 Nov 2024 at 06:45, Chet Ramey  wrote:

> On 11/12/24 8:17 PM, Grisha Levit wrote:
> > I'm not sure if this is the most idiomatic way to write the rule, but
> > if a libintl.h is generated, it needs to make it into the installed
> > headers directory to allow loadables to build.
>

AFAIK examples/loadables/Makefile.in already defines INTL_INC = @INTL_INC@,
so it seems to me that configure merely needs to set that to either
INTL_SRCDIR (if supplied) or INTL_LIBDIR (if built), or to whatever
external version is being used.

I assume you mean third-party loadables, right? None of the examples use
> any of the gettext or locale functions in libintl.
>

My option-handling revamp includes a new example loadable that does use
gettext, for the help text that accompanies a shopt/set-o option that is
defined by the loadable. (Since this would be a new capability, it seemed
like a good idea to demonstrate it.)

-Martin

[bug #66445] Use after free in change_to_directory function

[anonymous]

URL:
  

 Summary: Use after free in change_to_directory function
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Fri 15 Nov 2024 10:48:54 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: Fri 15 Nov 2024 10:48:54 AM UTC By: Anonymous
There two places, where use after free occurs in change_to_directory function
defined in cd.def file.
1. First place:
assign: Assigning: tdir = nolinks ? sh_physpath(t, 0) : sh_canonpath(t, 3).
571  tdir = nolinks ? sh_physpath (t, 0)
572 : sh_canonpath (t, PATH_CHECKDOTDOT|PATH_CHECKEXISTS);
573
574  ndlen = strlen (newdir);
575
576  /* Use the canonicalized version of NEWDIR, or, if canonicalization
577 failed, use the non-canonical form. */
578  canon_failed = 0;
6. Condition tdir, taking true branch.
7. Condition *tdir, taking false branch.
579  if (tdir && *tdir)
580free (t);
581  else
582{
8. Condition tdir, taking true branch.
9. freed_arg: free frees tdir.
583  FREE (tdir);
CID 6159462: (#1 of 1): Use after free (USE_AFTER_FREE)
10. use_after_free: Using freed pointer t.
584  tdir = t;
585  canon_failed = 1;

2. Second place:
CID 6159485: (#1 of 1): Use after free (USE_AFTER_FREE)
14. use_after_free: Using freed pointer tdir.
628  r = chdir (nolinks ? newdir : tdir);








___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

[bug #66444] Use after free in expand_string_dollar_quote function

[anonymous]

URL:
  

 Summary: Use after free in expand_string_dollar_quote
function
   Group: The GNU Bourne-Again SHell
   Submitter: None
   Submitted: Fri 15 Nov 2024 09:26:31 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: Fri 15 Nov 2024 09:26:31 AM UTC By: Anonymous
The static analyzer showed an error in function expand_string_dollar_quote
(file: subst.c), where t variable is used after free:
 freed_arg: free frees t.
4290  free (t);
CID 6159498: (#1 of 1): Read from pointer after free (USE_AFTER_FREE)
212. use_after_free: Using freed pointer t.
4291  if (singlequote_translations &&
4292((news-sindex-1) != translen || STREQN (t, trans,
translen) == 0))
4293t = sh_single_quote (trans);
4294  else
4295t = sh_mkdoublequoted (trans, translen, 0);
4296  sindex = news;
4297}

This is clearly a bug, we have free(t) and in the next instruction the t
variable is used directly:
4291  if (singlequote_translations &&
4292((news-sindex-1) != translen || STREQN (t, trans,
translen) == 0))







___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/


signature.asc
Description: PGP signature

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

[Martin D Kealey]

On Fri, 15 Nov 2024 at 00:20, Chet Ramey  wrote:

> On 11/13/24 11:40 PM, Martin D Kealey wrote:
>
> > The fact that pipeline components are implicitly run in subshells is
> > arguably not highlighted well enough [...]
>


> The man page states that explicitly.
>

I know, but "explicitly" is not the same as "highlighted", let alone "well
enough".

Novice shell users tend to have a weak-at-best grasp of process separation,
and an abysmal-to-non-existent grasp of subshells, so the documentation for
Bash needs to drive those home at every opportunity.

I know that the FSF believes that "info" is the *one true documentation
format*, but that's pretty unrealistic in most environments. If people want
documentation from the command line, they type "man whatever", because it
works. (Or they ask Facebook or Bing or Google or Reddit or StackExchange,
and get ... wherever.)

The manual page runs to 7000+ lines, all in one document, so most people
*don't* read it from start to finish; rather they search for keywords.

If a warning or explanation isn't shown in response to such a search, it
might as well not exist.

There are no hyperlinks in man pages. Most $PAGER programs have a search
function, but it's a challenge to convince a human under the age of 40 to
use it. So I conclude that *writing* "see also" is not enough; any warning
text itself has to be repeated, immediately adjacent to each description
where it's germane.

And yes that would probably blow up the current 7000 lines to 1+ lines.
Perhaps the Bash man page needs to be broken into many separate pages,
including one-per-builtin.

-Martin

PS: I would envisage maybe as many as a hundred repetitions of something
like this: *“The built-in Foo command changes the Bar setting only in the
current process, which may or may not be your script's main process. Please
read "man bash-subshell" for an explanation of when new processes are
created and how this affects **each of the **built-in commands”* or this: *“The
Zot construct creates a subshell. This will limit the effects of built-in
commands within it, preventing them from changing settings in the main
process. Please read "man bash-subshell" for an explanation of when new
processes are created and how this affects **each of the **built-in
commands”.*

Re: The 'source x' command doesn't keep variables set by x when source output is piped into other command

[Robert Elz]

Date:Sat, 16 Nov 2024 14:05:17 +1000
From:Martin D Kealey 
Message-ID:  


  | I know, but "explicitly" is not the same as "highlighted", let alone "well
  | enough".

Please, nothing at all like you're suggesting.   Man pages are not, and
not intended to be, tutorials.

People who need tutorials should go get exactly that - there are books on
shell programming, and I expect, at least one that is precisely on bash.

If that kind of thing isn't good enough, talk to their authors.   Refer
obvious newbies to those, not to the man page.

kre

ps: that is perhaps except for the separate man pages for built-ins.
I have been considering doing something like that - document the generic
properties of the built-ins, make passing reference to some shell specific
variations, and refer the user to their specific shell documentation for
shell specific details.   Then the shell man page needs a reference to the
man page for the built-in, followed by any variations that particular shell
makes to how it works.