[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 16:23:21 -0400 |
On Mon, Oct 21, 2024 at 11:50 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 10/21/24 12:15 AM, Zachary Santer wrote:
> >
> > The nontrivial stuff I do is still being run by bash 4.2 at the
> > moment, and I'm not willing to give up procsubs.
>
> Probably something to take up with your distro (Red Hat/Centos, right?)
RHEL 7. Something more recent is coming ... eventually.
On Mon, Oct 21, 2024 at 11:53 AM Chet Ramey <chet.ramey@case.edu> wrote:
>
> On 10/21/24 9:54 AM, Robert Elz wrote:
> > From the earlier message (just replying to this one to get the
> > new Subject: which fits better)...
> >
> > zsanter@gmail.com said:
> > | I can work around function names needing to be valid shell 'name's by
> >
> > That one bash could easily fix if it wanted to, there's never been a
> > POSIX requirement that only "name"s can be used as function names.
>
> No, the original 1992 standard required it:
>
> "The function is named fname; it shall be a name (see 3.1.5)."
>
> 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? That's how I would interpret kre's quote from
the standard. Otherwise, it's contradicting itself.
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
Koichi Murase's ble.sh has a bunch of function names with '/', '-',
'.', etc. in the names.
https://github.com/akinomyoga/ble.sh/
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.
So my script might violate POSIX, but POSIX allows shell
implementations to work with those function names anyway? I don't mind
my script violating POSIX. It's probably not going to run in any other
shell than bash anyway.
- Re: 'wait -n' with and without id arguments, Chet Ramey, 2024/10/17
- Re: 'wait -n' with and without id arguments, Zachary Santer, 2024/10/20
- Re: 'wait -n' with and without id arguments, Grisha Levit, 2024/10/20
- posix vs default mode nonsense, Zachary Santer, 2024/10/21
- Re: posix vs default mode nonsense, Chet Ramey, 2024/10/21
- Re: posix vs default mode nonsense,
Zachary Santer <=
- Re: posix vs default mode nonsense, Lawrence Velázquez, 2024/10/21
- Re: posix vs default mode nonsense, Zachary Santer, 2024/10/21
- Re: posix vs default mode nonsense, Chet Ramey, 2024/10/22
- Re: posix vs default mode nonsense, Zachary Santer, 2024/10/25
- Re: posix vs default mode nonsense, Chet Ramey, 2024/10/26
- Re: posix vs default mode nonsense, Robert Elz, 2024/10/21
- Re: posix vs default mode nonsense, Chet Ramey, 2024/10/21
- Re: 'wait -n' with and without id arguments, Lawrence Velázquez, 2024/10/20
- Re: 'wait -n' with and without id arguments, Chet Ramey, 2024/10/21