3 ms·

If I had to wish only one thing in context of shell scripts, it would be to be able to separate passing back the actual result from a function from stdout/stder

If I had to wish only one thing in context of shell scripts, it would be to be able to separate passing back the actual result from a function from stdout/stderr/logging without messing with boilerplate around non-standard file descriptors/named pipes/temp files etc.

__MatrixMan__ 5y ago
What, besides the actual result, do you write to stout? (And shouldn't it go to stderr instead?)
- noisy_boy 5y ago
  Typically informational messages/log message. Ideally yes logging should go to stderr but some applications that intercept the file descriptors consider anything to stderr as error and it is not always possible to change the handling for those applications. E.g. Octopus Deploy[0] does this: it doesn't outright fail the step assuming other "successful" steps happen after that but if the last command writes to stderr, it would; I use explicit exit statements as a workaround to handle this. [0]: https://octopus.com/ https://octopus.com/
  - __MatrixMan__ 5y ago
    I guess I just wanted to be on a high horse and declare that anybody who puts something other than what you asked for on stdout is doing it WRONG. But you're right, fixing the universe to fit the convention isn't always in the cards. If I could design it all from scratch I'd have a convention for getting a program to tell me: - info, user prompts, debug -> stderr - foo data, bar data -> stdout That way I could use those defaults sometimes, but other times specify per-execution preferences that would route the data differently.
    - noisy_boy 5y ago
      I was looking more into this and found something interesting[0]: > A variable can be assigned the nameref attribute using the -n option to the declare or local builtin commands (see Bash Builtins) to create a nameref, or a reference to another variable. This allows variables to be manipulated indirectly. Whenever the nameref variable is referenced, assigned to, unset, or has its attributes modified (other than using or changing the nameref attribute itself), the operation is actually performed on the variable specified by the nameref variable’s value. A nameref is commonly used within shell functions to refer to a variable whose name is passed as an argument to the function. So something like below: set_var() { local -n vname=$1 # use nameref for indirection # some processing and assign value vname="abcd" } use_var() { local output set_var output # call function to populate the variable echo "output=$output" unset -n output } use_var I guess this is pretty close to "clean". Unfortunately, it is only available in bash 4.3, if I'm not wrong, so I don't have a choice to use it (our hosts use 4.2.x). [0]: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameters.html https://www.gnu.org/software/bash/manual/html_node/Shell-Par...

__MatrixMan__ 5y ago

What, besides the actual result, do you write to stout? (And shouldn't it go to stderr instead?)

noisy_boy 5y ago
Typically informational messages/log message. Ideally yes logging should go to stderr but some applications that intercept the file descriptors consider anything to stderr as error and it is not always possible to change the handling for those applications. E.g. Octopus Deploy[0] does this: it doesn't outright fail the step assuming other "successful" steps happen after that but if the last command writes to stderr, it would; I use explicit exit statements as a workaround to handle this. [0]: https://octopus.com/ https://octopus.com/
- __MatrixMan__ 5y ago
  I guess I just wanted to be on a high horse and declare that anybody who puts something other than what you asked for on stdout is doing it WRONG. But you're right, fixing the universe to fit the convention isn't always in the cards. If I could design it all from scratch I'd have a convention for getting a program to tell me: - info, user prompts, debug -> stderr - foo data, bar data -> stdout That way I could use those defaults sometimes, but other times specify per-execution preferences that would route the data differently.
  - noisy_boy 5y ago
    I was looking more into this and found something interesting[0]: > A variable can be assigned the nameref attribute using the -n option to the declare or local builtin commands (see Bash Builtins) to create a nameref, or a reference to another variable. This allows variables to be manipulated indirectly. Whenever the nameref variable is referenced, assigned to, unset, or has its attributes modified (other than using or changing the nameref attribute itself), the operation is actually performed on the variable specified by the nameref variable’s value. A nameref is commonly used within shell functions to refer to a variable whose name is passed as an argument to the function. So something like below: set_var() { local -n vname=$1 # use nameref for indirection # some processing and assign value vname="abcd" } use_var() { local output set_var output # call function to populate the variable echo "output=$output" unset -n output } use_var I guess this is pretty close to "clean". Unfortunately, it is only available in bash 4.3, if I'm not wrong, so I don't have a choice to use it (our hosts use 4.2.x). [0]: https://www.gnu.org/software/bash/manual/html_node/Shell-Parameters.html https://www.gnu.org/software/bash/manual/html_node/Shell-Par...