Ubuntu – How to import output from a command as a command in Bash

bashcommand line

System

Linux hosek 4.15.0-48-generic #51-Ubuntu SMP Wed Apr 3 08:28:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Issue

I need to get output as commands, in a bash script, for storing variables.

Example

sed -n '/# Main configuration./,/# Websites./p' webcheck-$category.cfg | sed '1,1d' | sed '$ d'

This command returns these lines:

email_sender='some@email.com'
email_recipients='another@email.com'

How can I read/run these output/lines as commands in script? Is storing this output to the file and then read it by source command only way?

I tried | source at the end of the command, but it reads only from files.

I tried echo at the beginning, but that had no effect.

Thanks.

Best Answer

As pLumo showed you, you can indeed source them. However, I would recommend against this. If you have something like this:

source <(sed -n '/# Main configuration./,/# Websites./p' webcheck-$category.cfg | sed '1,1d' | sed '$ d')

echo "$email_sender"

Then, a year later when you come back and look at this script, you will have no idea where this email_sender variable is coming from. I suggest you instead change the command and use one that returns only the variable's value and not its name. That way, you can easily keep track of where each variable comes from:

email_sender=$(grep -oP 'email_sender=\K.*' webcheck-$category.cfg)
email_recipients=$(grep -oP 'email_recipients=\K.*' webcheck-$category.cfg)

Short Answer

In your question, the second command uses neither the . shell builtin nor the source builtin. Instead, you are actually running the script in a separate shell, by invoking it by name like you would with any other executable file. This does give it a separate set of variables (though if you export a variable in its parent shell, it will be an environment variable for any child process, and therefore will be included in a child shell's variables). If you change the / to a space, then that would run it with the . built-in, which is equivalent to source.

Extended Explanation

This is the syntax of the source shell built-in, which executes the contents of a script in the current shell (and thus with the current shell's variables):

source testenv.sh

This is the syntax of the . built-in, which does do the same thing as source:

. testenv.sh

However, this syntax runs the script as an executable file, launching a new shell to run it:

./testenv.sh

That is not using the . built-in. Rather, . is part of the path to the file you are executing. Generally speaking, you can run any executable file in a shell by invoking it with a name that contains at least one / character. To run a file in the current directory, preceding it by ./ is thus the easiest way. Unless the current directory is in your PATH, you cannot run the script with the command testenv.sh. This is to prevent people from accidentally executing files in the current directory when they intend to execute a system command or some other file that exists in some directory listed in the PATH environment variable.

Since running a file by name (rather than with source or .) runs it in a new shell, it will have its own set of shell variables. The new shell does inherit the environment variables from the calling process (which in this case is your interactive shell) and those environment variables do become shell variables in the new shell. However, for an shell variable to be passed to the new shell, one of the following must be the case:

The shell variable has been exported, causing it to be an environment variable. Use the export shell built-in for this. In your example, you can use export MY_VAR=12345 to set and export the variable in one step, or if it is already set you can simply use export MY_VAR.
The shell variable is explicitly set and passed for the command you're running, causing it be an environment variable for the duration of the command being run. This usually accomplishes that:
```
MY_VAR=12345 ./testenv.sh
```
If MY_VAR is a shell variable that hasn't been exported, you can even run testenv.sh with MY_VAR passed as an environment variable by setting it to itself:
```
MY_VAR="$MY_VAR" ./testenv.sh
```

`./` Syntax for Scripts Requires a Hashbang Line to Work (Correctly)

By the way, please note that, when you invoke an executable by name as above (and not with the . or source shell built-ins), what shell program is used to run it is not usually determined by what shell you're running it from. Instead:

For binary files, the kernel may be configured to run files of that particular type. It examines the first two bytes of the file for a "magic number" that indicates what sort of binary executable it is. This is how executable binaries are able to run.

This is, of course, extremely important, because a script can't run without a shell or other interpreter, which is an executable binary! Plus, many commands and applications are compiled binaries rather than scripts.

(#! is the text representation of the "magic number" indicating a text executable.)
For files that are supposed to run in a shell or other interpreted language, the first line looks like:
```
#!/bin/sh
```
/bin/sh may be replaced with whatever other shell or interpreter is intended to run the program. For example, a Python program might start with the line:
```
#!/usr/bin/python
```
These lines are called hashbang, shebang, and a number of other similar names. See this FOLDOC entry, this Wikipedia article and Is #!/bin/sh read by the interpreter? for more information.
If a text file is marked executable and you run it from your shell (like ./filename) but it doesn't begin with #!, the kernel fails to execute it. However, seeing that this has happened, your shell will try to run it by passing its name to some shell. There are few requirements placed on what shell that is ("the shell shall execute a command equivalent to having a shell invoked..."). In practice, some shells--including bash^*--run another instance of themselves, while others use /bin/sh. I highly recommend you avoid this and use a hashbang line instead (or run the script by passing it to the desired interpreter, e.g., bash filename).

^*_{GNU Bash manual, 3.7.2 Command Search and Execution: "If this execution fails because the file is not in executable format, and the file is not a directory, it is assumed to be a shell script and the shell executes it as described in Shell Scripts."}

Ubuntu – ubuntu man command display blank pages

The solution has been posted canonical launchpad:

Seems that problem in apparmor profile loading on older kernels. I
have the same issue on custom kernel 4.4, but with ubuntu kernel 4.15
everything ok.

Workaround for older kernels: 
apt install apparmor-utils 
aa-disable /usr/bin/man

Upstream Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=889617

It works on kernel 4.12 too!

Best Answer

Related Solutions

Ubuntu – difference between “.” and “source” in bash, after all

Short Answer

Extended Explanation

./ Syntax for Scripts Requires a Hashbang Line to Work (Correctly)

Ubuntu – ubuntu man command display blank pages

Related Question

`./` Syntax for Scripts Requires a Hashbang Line to Work (Correctly)