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>
abross...@reyl.com<mailto:abross...@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 <g...@wooledge.org>
Sent: Friday, June 14, 2024 1:27 PM
To: bug-bash@gnu.org
Cc: Alain BROSSARD <abross...@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.
