Re: [Help-bash] How to print a bash variable in the most succinct way?

[Peng Yu]

On Tue, Aug 16, 2016 at 7:38 AM, Greg Wooledge <address@hidden> wrote:
> On Mon, Aug 15, 2016 at 10:36:23PM -0500, Peng Yu wrote:
>> https://www.gnu.org/software/parallel/env_parallel.html
>
> "env_parallel is a shell function that exports the current environment
> to GNU parallel."
>
> GRRAAAHHHHHHH!!!  NO!  STOP IT!  STOP IT!!!
>
> Seriously.  WASN'T Node.js BAD ENOUGH?!
>
> Why do people keep DOING THIS?!
>
>> env_parallel uses something like `declare -p` to extract the current
>> environment so that the variables and functions in the current bash
>
> DO YOU KNOW HOW TO MAKE THE ENVIRONMENT AVAILABLE TO YOUR CHILD PROCESSES?
>
> I WILL TELL YOU!
>
> YOU DO NOTHING.
>
> NOTHING!
>
> YOU DO NOTHING.
>
> THE ENVIRONMENT IS AUTOMATICALLY AVAILABLE TO CHILD PROCESSES.
>
> THAT IS WHAT IT MEANS TO BE THE ENVIRONMENT.
>
> THAT IS THE ENTIRE POINT OF HAVING AN ENVIRONMENT.
>
>
>
>
> OK, now listen up.  I know you think I am an asshole now.  Maybe I am.
> Too bad.  I am going to try to pound some sense into you anyway.
> Because I'm too stupid to stop trying.
>
> When you invoke a child process such as GNU parallel, it inherits
> the environment from its parent.

Only the exported variables can be inherited. But I don't want to
export every variables as it will make my code more difficulty to
read.

> That environment is, traditionally, a set of variables that you have
> explicitly exported (marked as part of the environment by using the
> "export" command).
>
> In addition, bash has the ability to export FUNCTIONS through the
> environment.  Again, you do this by marking them with the "export"
> command.  Read "help export" to find out more.
>
> When you (a bash script) invoke a child process (e.g. find or parallel)
> which then invokes ANOTHER bash script as ITS child, then the
> environment from the grandparent bash shell is all handed down
> AUTOMATICALLY to the grandchild bash shell.
>
> This includes every variable and every function that you have exported.
>
> You don't need some stupid, awful, NODE.JS-LIKE (there are very few
> insults stronger than this) HACK that tries to create a secondary
> "environment" of some kind for you.
>
> You already HAVE an environment.
>
> Just use it.
>
>
>
>
> But wait, there's more!  I know you won't believe me.  Nobody ever
> believes anything I tell them until I reach physically through the
> Internet and throttle them.  So here is an example.
>
> First I will make up a function foo.  It will take one filename as
> an argument.  It will do something VITALLY IMPORTANT to that filename.
> So important that we had to do it in a bash function (because
> obviously just making it a script and putting it in $PATH would have
> been FAR TOO EASY, and easy solutions are not allowed).
>
> address@hidden:~$ foo() { echo "<$1>"; }
>
> OK, there is my super-important bash function that absolutely positively
> had to be done as a function instead of a script.
>
> Now I will export it.
>
> address@hidden:~$ help export | grep function
>       -f        refer to shell functions
>       -p        display a list of all exported variables and functions
> address@hidden:~$ export -f foo
>
> Now I will use find to recurse through my file(s) and/or directory(ies)
> and apply this function to each one, using the MAAAAGIC of bash's
> environment.
>
> address@hidden:~$ find .bashrc .profile -exec bash -c 'for f; do foo "$f"; 
> done' _ {} +
> <.bashrc>
> <.profile>
>
> Presto!  Abracadabra!  Expelliarmus!
>
> Any more questions?  Read http://mywiki.wooledge.org/UsingFind for answers.
>
> Wait, you've STILL got questions?  You want to know how to make bash
> export fucking god-damned ALIASES through the environment or something?
> You use the BASH_ENV variable to point to a file that contains your
> alias definitions, so that the grandchild shell will re-invent them.
>
>
> What, you're still here?  Now you want to export ARRAY VARIABLES through
> the environment?  Well, you can't.  Just stop trying.  Work around this
> limitation by redesigning your software.
>
>
> If GNU env_parallel breaks in GNU bash because it tries to serialize an
> array variable into an environment variable and gets it wrong, then file
> a bug report against GNU env_parallel.  Meanwhile, STOP USING IT!
>
> Seriously, any time you see "this software package modifies your shell
> dot files, creating a series of new functions..." you should see HUGE
> RED WARNING FLAGS.  This is bad.  You should not be using it.



-- 
Regards,
Peng