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
