On Mon, Oct 21, 2024 at 11:50 AM Chet Ramey <chet.ra...@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.ra...@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)... > > > > zsan...@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.
