RE: set -a leads to truncated output from ps

[Alain BROSSARD]

Hi Greg,

    The original problem started with I added “echo $PATH | grep ….” Into a 
“site” configuration file source’d from our vendor’s scripts.  So yes, this 
whole issue is present in scripts.  It took me quite a while to figure out why 
our vendor’s scripts were now failing and on how to reproduce the issue 
interactively.

    ps axww   isn’t impacted, but the scripts use ‘ps ax’.

   In a normal interactive environment, one would never use “set -a” and as 
such the issue is never seen in interactive mode.  I’ve never used personally, 
but as set -a is executed by our 3rd party script, I have to deal with it.

   Using “shopt -u checkwinsize” is a good work-around, much simpler that what 
I came up with. But again, before thinking about using this, you need to know 
about the whole issue and what the vendor does in its own script.  Very error 
prone behavior.

Regards,
Alain


[cid:ISP-REYL_HubSWS_Col_email_v2_88f4ea19-df87-4cc1-aef3-c28f2127924c.png]<http://www.reyl.com>

Alain BROSSARD
System & Network Administrator
Technology

D +41 22 816 8607<tel:+41%2022%20816%208607>
M +41 79 612 2336<tel:+41%2079%20612%202336>
T +41 22 816 8600<tel:+41%2022%20816%208600>
F +41 22 816 8009<tel:+41%2022%20816%208009>
abrossard@reyl.com<mailto:abrossard@reyl.com>

REYL & Cie SA
Rue du Rhône 4
1204 Genève
www.reyl.com<https://www.reyl.com>

[cid:SUCCES.TOGETHER_RVB_email_345119d7-0ea9-4fc1-b2e0-c31313eae094.png]
________________________________
The information contained in email messages from REYL & Cie SA may contain 
confidential, proprietary or legally privileged information and is intended 
only for the use of the addressee named above. No confidentiality or privilege 
is waived or lost by any mis-transmission. If you are not the addressee of this 
email message, you must not use, distribute, copy it in any form or take any 
action in reliance on it. If you have received this email message by error, 
please notify us immediately by replying to the message and delete it from your 
computer. If there are any attachments to the email messages that you received 
in error, kindly refrain from opening them and do not download or save them to 
your computer. In accordance with industry standards and practices, and to 
comply with our legal and regulatory retention requirement REYL & Cie SA 
monitors and retains email messages for a period of time in accordance with its 
policies, guidelines and procedures. Email transmission cannot be guaranteed to 
be secured or error-free as information could be intercepted, corrupted, lost, 
destroyed, arrive late or incomplete, or contain viruses. REYL & Cie SA is not 
liable for any unproper or incomplete transmission of the information contained 
in email messages or for any delay it their receipt. Some publications included 
in email message may be advertising material (pursuant to Art. 68 of the 
Federal Act on Financial Services, Financial Services Act of 15 June 2018) for 
financial services or for financial instruments. For any financial instruments 
mentioned, we will be happy to provide you with additional documents at any 
time and free of charge, such as a key information document pursuant to Art. 58 
et seq. of the Financial Services Act, a prospectus pursuant to Art. 35 et seq. 
of the Financial Services Act or an equivalent foreign product information 
sheet, e.g. a basic information sheet pursuant to Regulation EU 1286/2014 for 
packaged investment products for retail investors and insurance investment 
products (PRIIPS KID). We consider your inquiries about our products and 
services as a request to contact you and send you relevant information.
From: Greg Wooledge <greg@wooledge.org>
Sent: Friday, June 14, 2024 1:27 PM
To: bug-bash@gnu.org
Cc: Alain BROSSARD <abrossard@reyl.com>
Subject: Re: set -a leads to truncated output from ps

ZjQcmQRYFpfptBannerEnd

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.