coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] printenv: add feature to print names only


From: Pádraig Brady
Subject: Re: [PATCH] printenv: add feature to print names only
Date: Wed, 14 Dec 2022 10:54:33 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.0

On 13/12/2022 21:22, Gianluca Mascolo wrote:
---- Il mar, 13 dic 2022 14:04:31 +0100, Pádraig Brady  ha scritto ---

  >
  >
  > This has some merit,
  > given that's it's awkward to postprocess printenv output
  > in the presence of multiline env values.
  >
  > Could you detail some use cases for this?
  >
  > thanks,
  > Pádraig
  >

I think that it may be useful in a couple of cases at least:
1) I work remotely and during online meetings I often need to share my screen. 
Sometimes I need to check if a variable containing an authentication token is 
exported locally before executing a command without showing it's content to 
remote attendees. At the moment, I use an alias for that purpose:
alias lsenv='printenv  | grep --color=never -oE "^[^=]+"'

2) It may be useful to print some information about the current environment of 
CI/CD pipeline scripts for debugging purposes and be sure that nothing 
sensitive will be displayed (although many CI/CD systems automatically mask 
those kinds of values with asterisks).

Using printenv directly for these scopes is just a convenience, and it can be 
done in other ways, but I think that embedding this small feature into printenv 
would be nice.

Thanks for the extra details.
Upon consideration the existing NUL support should support this robustly.
For e.g.:

  printenv -0 | cut -z -f1 -d= | tr '\0' '\n'

BTW for completeness I find the following useful to
display the _startup_ environment for any process on Linux:

  tr '\0' '\n' < /proc/$$/environ

Also for the first use case to directly test if a var is set one can:

  test ${var+x} && echo set

or more directly like:

  echo ${var+set}

So I'd be 70:30 against adding --name-only support.

thanks,
Pádraig



reply via email to

[Prev in Thread] Current Thread [Next in Thread]