bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: posix vs default mode nonsense


From: Zachary Santer
Subject: Re: posix vs default mode nonsense
Date: Mon, 21 Oct 2024 21:04:29 -0400

On Mon, Oct 21, 2024 at 5:07 PM Lawrence Velázquez <vq@larryv.me> wrote:
>
> On Mon, Oct 21, 2024, at 4:23 PM, Zachary Santer wrote:
> > On Mon, Oct 21, 2024 at 11:53 AM Chet Ramey <chet.ramey@case.edu> wrote:
> >>
> >> That changed to an application requirement in 2001.
> >
> > Pardon my ignorance, but as an "application requirement," is that
> > saying what shell scripts are allowed to do, rather than what bash
> > itself is allowed to do?
>
> Yes.  A shell is an "implementation", not an "application".
>
> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap02.html#tag_02_01
> https://pubs.opengroup.org/onlinepubs/9799919799/basedefs/V1_chap02.html#tag_02_02
>
>
> > Don't know how much weight the Google Shell Style Guide carries here,
> > or with the Austin Group, but:
> >>  If you’re writing a package, separate package names with :: [in function 
> >> names].
> > https://google.github.io/styleguide/shellguide.html#function-names
>
> Google uses default-mode bash almost exclusively, so their guide
> is not relevant to a discussion about POSIX mode.
>
> https://google.github.io/styleguide/shellguide.html#s1.1-which-shell-to-use
>
>
> > Koichi Murase's ble.sh has a bunch of function names with '/', '-',
> > '.', etc. in the names.
> > https://github.com/akinomyoga/ble.sh/
>
> I wouldn't be surprised if POSIX mode broke ble.sh in a number of
> ways.  Using interactive shells in POSIX mode is surely uncommon.
>
>
> > I've got some functions that look like I'm overloading the increment
> > operator in C++:
> > abc::++ () { ... }
> > xyz::++ () { ... }
> > ++ () { ... }
> >
> > Those functions spent some time as "increment"* before I realized I
> > could do that, and I couldn't resist the urge.

I bring up the Google Shell Style Guide, ble.sh, and my own use case
simply to point out that there are uses for function names that aren't
valid "name"s. I'm not trying to claim that POSIX mode must support
everything that Google, Koichi, and I are doing with bash.

> > So my script might violate POSIX [...] I don't mind my script
> > violating POSIX. It's probably not going to run in any other
> > shell than bash anyway.
>
> Yes, a script that uses those functions is nonconformant, but that
> only matters if you're aiming for conformance in the first place.
>
>
> > but POSIX allows shell implementations to work with those
> > function names anyway?
>
> Yes.

So this aspect of POSIX mode is unnecessary, and maybe the biggest
barrier to its wider use. I don't have any other reason not to use it,
at least in bash 5.3.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]