On Fri, Jun 14, 2024 at 07:28:41AM +0000, Alain BROSSARD wrote: > Honestly, I don't know where to go with this issue. Bash's behavior > should be consistent and easily understood in order to have reliable scripts. > Clearly this case doesn't respect this. > I would suggest to put LINES and COLUMN out of scope of the behavior of > "set -a", or at the very least make all these interactions explicit within > the man page. If it had been documented, I would have saved myself many > hours of work as I did read the documentation once I had pinned down that > "set -a" is the command which caused those script to fail. Though the real > culprit, in the end, might be checkwinsize default behavior if one wanted to > blame a single member of this trio.
The biggest surprise for me in all of this is that checkwinsize is enabled in *scripts*. Your demonstrations were all done with interactive shells, and I'm not surprised by the behavior there. But now you're claiming this also happens in a script? That surprises me. Maybe the best solution would be to disable checkwinsize in noninteractive shells by default. Looking at the CHANGES file, checkwinsize became enabled by default in bash 5.0. That's relatively recent. I'm not sure what the rationale was, behind making that change. Meanwhile, for your own scripts which use set -a and then call a broken implementation of ps that doesn't support "ww" correctly... my best suggestion is to do a "shopt -u checkwinsize" yourself, prior to the set -a. And/or complain to your OS vendor that their version of ps needs to ignore the COLUMNS environment variable when using the "ww" option. The version in Debian 12 seems fine to me: hobbit:~$ COLUMNS=60 ps ww -fp 192331 UID PID PPID C STIME TTY STAT TIME CMD greg 192331 192024 0 07:11 tty1 Sl 0:00 /opt/google/chrome/chrome --type=renderer --crashpad-handler-pid=192013 --enable-crash-reporter=CB81BA40-8F5C-190E-68BD-10B3F798FC39, --change-stack-guard-on-fork=enable --lang=en-US --num-raster-threads=4 --enable-main-frame-before-activation --renderer-client-id=24 --time-ticks-at-unix-epoch=-1717084382798067 --launch-time-ticks=1279127066717 --shared-files=v8_context_snapshot_data:100 --field-trial-handle=3,i,8617856633869464935,3483640836820097713,262144 --variations-seed-version=20240613-180209.895000 Finally, one last bit of unsolicited advice, which may or may not cause you to become angry: parsing the output of "ps" in scripts is a dirty hack, and should not be your best method of solving whatever the underlying issue is. If you're trying to "see if it's already running before you start it" then the preferred solution is to implement "it" as a managed service (via systemd, runit, daemontools, or whatever you use for services, preferably not sysv-rc, but even that should have OS-specific hacks to allow some kind of approximation of service management). And yes, there are ugly situations where even the best service managers in the world can't fully express a solution, and "ps" parsing *might* have a role to play... but at least you should consider other options if you haven't already.
