Hi,
You are correct, export COLUMNS does truncate, I had made the mistake of
replaying the previous execution of ps which was with “axww”.
Something does go wrong once COLUMNS is in the environment, it seems that in
that case, it can get modified when executing a pipe’d command.
As the following examples show, we have narrowed this down to two things
1. set -a causes, in certain situation, to be clarified, but the pipe
below gives us a big hint, the COLUMNS variable to be exported when it should
NOT be
2. COLUMNS gets modified, by the shell, when a command with a ‘|’ is
processed
3. Those two conditions trigger what I saw as a bug in the output of “ps
ax”. Now it seems that “ps” is the revealer and not buggy as I suspected at
some point.
Starting a new bash :
host:/$ export COLUMNS=60
host:/$ ps ax | grep java | head -1
2051669 ? Sl 0:17 /usr/lib/jvm/java-17-openjdk-am
host:/$ export COLUMNS=80
host:/$ ps ax | grep java | head -1
2051669 ? Sl 0:17 /usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xms2g
host:/$ export COLUMNS=120
host:/$ ps ax | grep java | head -1
2051669 ? Sl 0:17 /usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xms2g
-Xmx2g -server -XX:+UseG1GC -XX:MaxGCPau
host:/$ ps ax | grep java | head -1 ### next output should be the
same as previous, but it is truncated
2051669 ? Sl 0:17 /usr/lib/jvm/java-17-openjdk-amd64/bin/java -Xms2g
-Xmx2g -server -XX:+Us
host:/$ echo $COLUMNS # COLUMNS was reset by bash
102
My conclusion is that the variable COLUMNS gets “reset” when there is a pipe
in a command and further gets EXPORTED if “set -a” was set before hand :
host:/$ COLUMNS=80
host:/$ echo $COLUMNS
80
host:/$ echo $COLUMNS
80
host:/$ echo $COLUMNS | cat
80
host:/$ echo $COLUMNS
102
PS1 is :
\[\e]0;\u@\h: \w\a\]${debian_chroot:+($debian_chroot)}\u@\h:\w\$
I would challenge the fact that “set -a” should move COLUMNS to the
environment when it gets modified by bash itself : not the expected behaviour.
@ Robert Elz, the POSIX definition does put an additional spin to this. I was
going by the very short explanation of set -a in the bash man page.
And I would challenge the fact that COLUMNS gets modified when a command
with a ‘|’ is executed. There is no way for a bash user or bash script writer
to expect such a behaviour in unforeseen circumstances. Also, it basically
makes “set -a” too dangerous to use, so why bother implementing it if it
shouldn’t be used ? That last bit is maybe a bit of a stretch, but you met my
meaning.
I do believe that this must be considered as a bug as it breaks scripts which
otherwise work perfectly. I added the following line in a file which is
getting source’d to define variables. I was not aware that the caller had set
“-a”. In fact, scripts should not be so vulnerable to a change to a bash
variable made by the caller. ( I did describe a work-around using “echo $-“
within a $( command ) in my bug report.)
echo $PATH | grep -q xx/scripts || PATH=${PATH}:/xx/scripts
I do not believe that adding this to a bash file should cause a failure
100’s of lines down in a totally different script bought from a third party
whose use of “set –a” I do not control. I do agree, now that I know about this
highly unexpected feature, that the third party should have used “ps axww”, but
then how could they expect the COLUMNS variable to be exported ? There is no
testing in the world which would catch a case like this. Hence, I do insist
that this is a bug.
The only way to prevent the ‘|’ from modifying COLUMNS is to put the
command within $( ) from my empirical testing which is worth what it is worth.
Not straight forward…
Regards,
Alain Brossard
[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: Oğuz <oguzismailuy...@gmail.com>
Sent: Thursday, June 13, 2024 5:34 PM
To: Alain BROSSARD <abross...@reyl.com>
Cc: bug-bash@gnu.org
Subject: Re: it, soRE: set -a leads to truncated output from ps
On Thursday, June 13, 2024, Alain BROSSARD <abrossard@ reyl. com> wrote: export
COLUMNS=60 ps ax | grep java The output isn’t truncated. It is on my machine.
You must have something in your PS1/PROMPT_COMMAND interfering. It is critical
that
ZjQcmQRYFpfptBannerStart
This Message Is From an Untrusted Sender
This message was sent from outside of REYL & CIE.
You have not previously corresponded with this sender.
Report Suspicious
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/HLcdjgI!MxEYukYE4uvJJ9SGuyrtmUtyxgDqcQpsSwickQko1rmmj40QVQAosVPivujK9u2RmQs9wNgZw070CenJrPwcZBqh8n_qzfSFUUvxznCKPMf6Gmaw_OFTc1yEWg$>
ZjQcmQRYFpfptBannerEnd
On Thursday, June 13, 2024, Alain BROSSARD
<abross...@reyl.com<mailto:abross...@reyl.com>> wrote:
export COLUMNS=60
ps ax | grep java
The output isn’t truncated.
It is on my machine. You must have something in your PS1/PROMPT_COMMAND
interfering.
It is critical that application’s behaviour do not get impacted by the shell
used to call them.
Even more reason to use `ps axww' instead of `ps ax'.
What do you think ?
I think there's at least one Bash bug involved here.
--
Oğuz
