Re: it, soRE: set -a leads to truncated output from ps

[alex xmb sw ratchev]

u can try

shopt -u checkwinsize

to disable that columns settings

On Thu, Jun 13, 2024, 8:29 PM Alain BROSSARD via Bug reports for the GNU
Bourne Again SHell <bug-bash@gnu.org> wrote:

> 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>
> 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: Oğuz <oguzismailuysal@gmail.com>
> Sent: Thursday, June 13, 2024 5:34 PM
> To: Alain BROSSARD <abrossard@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 <abrossard@reyl.com<mailto:
> 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 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
>
>