From Newsgroup: comp.unix.shell

1. lets say to set environmental variable I have:

PAGER=less ./tinybase -r <<'EOF'
x
y
z
EOF


2. now lets say to set environmental variable I have:

PAGER=less
./tinybase -r <<'EOF'
x
y
z
EOF

Case 1 always works while case 2 fails.

Does this mean, as it appears, PAGER *must* be on the same line (inline)?
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sat, 08 Nov 2025 15:04:53 +0000, Michael Sanders wrote:

1. lets say to set environmental variable I have:

PAGER=less ./tinybase -r <<'EOF'
x
y
z
EOF

2. now lets say to set environmental variable I have:

PAGER=less
./tinybase -r <<'EOF'
x
y
z
EOF

Case 1 always works while case 2 fails.

Does this mean, as it appears, PAGER *must* be on the same line (inline)?

Yes, in this circumstance.

In the shell, when you specify the setting of a variable
PAGER=less
the shell retains this setting for itself, and does not
pass it on to programs invoked from the shell.

To pass the variable onward to an invoked program, you either
have to
export PAGER
which makes the assignment available to any invoked program, in
it's inherited environment, or you have to
PAGER=less ./tinybase ...
which does not retain the setting in the shell, and only makes
the assignment available to the inherited program.

For instance, in my bash shell, I
$ # show that the shell does not know the environment variable "UNIQUE"
$ printenv | grep UNIQUE
$ # now, temporarily set UNIQUE, and pass it to printenv
$ UNIQUE=123 printenv | grep UNIQUE
UNIQUE=123
$ # Now show that the above command did not set UNIQUE in the shell
$ printenv | grep UNIQUE
$ # Nope, UNIQUE is not an environment variable
and
$ # set UNIQUE as a shell variable (should not wind up in the environment)
$ UNIQUE=def
$ # check if shell populated UNIQUE into it's environment variable list
$ printenv | grep UNIQUE
$ # Nope, UNIQUE is not an environment variable
$ # Now tell shell to populate UNIQUE into the environment variable list
$ export UNIQUE
$ # check if shell populated UNIQUE into it's environment variable list
$ printenv | grep UNIQUE
UNIQUE=def
$ # Yes, UNIQUE is an environment variable

HTH
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sat, 8 Nov 2025 15:36:10 -0000 (UTC), Lew Pitcher wrote:

[...]

HTH

Yes sir it very much does.
Added your reply to my notes, thank you.
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <10eno7c$2llvn$1@dont-email.me>,
Michael Sanders <porkchop@invalid.foo> wrote:

On Sat, 8 Nov 2025 15:36:10 -0000 (UTC), Lew Pitcher wrote:

[...]

HTH

Yes sir it very much does.
Added your reply to my notes, thank you.

To amplify a bit on Lew's excellent response.

I am assuming you are using bash. I don't care about being quote-unquote "portable" to ancient shells. I neither know nor care if or what parts of
what I write are not quote-unquote "portable".

1) As Lew noted, you can either do:

$ PAGER=less
$ export PAGER

or, equivalently:

$ export PAGER=less

And, in particular for this specific variable, one of the above (preferably
the later) is usually done "globally" - that is, in .profile (or similar).
It is rare that you'd want to set it only for one particular program (e.g., your tinybase program).

2) Generally, you only export what needs to be exported. So, sometimes you find that you need a non-exported variable to be exported just for the run
of a particular program or command. In that case, I frequently do
something like:

$ REPLY="$REPLY" someCommand

(REPLY is a frequently used variable that is usually *not* exported)
--
When someone tells me he/she is a Christian I check to see if I'm
still in possession of my wallet.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sat, 8 Nov 2025 16:05:14 -0000 (UTC), Kenny McCormack wrote:

In article <10eno7c$2llvn$1@dont-email.me>,
Michael Sanders <porkchop@invalid.foo> wrote:

On Sat, 8 Nov 2025 15:36:10 -0000 (UTC), Lew Pitcher wrote:

[...]

HTH

Yes sir it very much does.
Added your reply to my notes, thank you.

To amplify a bit on Lew's excellent response.

I am assuming you are using bash. I don't care about being quote-unquote "portable" to ancient shells. I neither know nor care if or what parts of what I write are not quote-unquote "portable".

1) As Lew noted, you can either do:

$ PAGER=less
$ export PAGER

or, equivalently:

$ export PAGER=less

And, in particular for this specific variable, one of the above (preferably the later) is usually done "globally" - that is, in .profile (or similar).
It is rare that you'd want to set it only for one particular program (e.g., your tinybase program).

2) Generally, you only export what needs to be exported. So, sometimes you find that you need a non-exported variable to be exported just for the run
of a particular program or command. In that case, I frequently do
something like:

$ REPLY="$REPLY" someCommand

(REPLY is a frequently used variable that is usually *not* exported)

Yes, was hoping to avoid exporting anything for obvious reasons.

Just wanted to make sure that inline:

FOO=BAR ./APP

was not a quirk. Makes perfect sense the more I think about it.
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-08, Michael Sanders <porkchop@invalid.foo> wrote:

1. lets say to set environmental variable I have:

PAGER=less ./tinybase -r <<'EOF'
x
y
z
EOF

2. now lets say to set environmental variable I have:

PAGER=less
./tinybase -r <<'EOF'

You need a backslash:

PAGER=less \
./rest-of-command ...

Otherwise you have two commands: a variable assignment followed by a
command, and not "run the program with this environment variable".

It will still work if you have a PAGER variable that is exported
to the environment.

I don't. This is a vanilla Ubuntu environment and I didn't go out
of my way to remove it:

$ env | grep PAGER
MANPAGER=/home/kaz/bin/mnpgr
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sat, 8 Nov 2025 17:23:44 -0000 (UTC), Kaz Kylheku wrote:

On 2025-11-08, Michael Sanders <porkchop@invalid.foo> wrote:

1. lets say to set environmental variable I have:

PAGER=less ./tinybase -r <<'EOF'
x
y
z
EOF


2. now lets say to set environmental variable I have:

PAGER=less
./tinybase -r <<'EOF'

You need a backslash:

PAGER=less \
./rest-of-command ...

Otherwise you have two commands: a variable assignment followed by a
command, and not "run the program with this environment variable".

It will still work if you have a PAGER variable that is exported
to the environment.

I don't. This is a vanilla Ubuntu environment and I didn't go out
of my way to remove it:

$ env | grep PAGER
MANPAGER=/home/kaz/bin/mnpgr

That backslash is a good point Kaz.
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

In article <10enuh9$2noil$1@dont-email.me>,
Michael Sanders <porkchop@invalid.foo> wrote:
...

You need a backslash:

PAGER=less \
./rest-of-command ...

That backslash is a good point Kaz.

Not really. I think he's just messin' with ya.

Putting the backslash there is just another way of putting it all on the
same line.
--
Those on the right constantly remind us that America is not a
democracy; now they claim that Obama is a threat to democracy.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sat, 8 Nov 2025 17:43:09 -0000 (UTC), Kenny McCormack wrote:

That backslash is a good point Kaz.

Not really. I think he's just messin' with ya.

Putting the backslash there is just another way of putting it all on the
same line.

Exactly: an alternate to (the same as) inline.
--
:wq
Mike Sanders
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sat, 8 Nov 2025 15:04:53 -0000 (UTC), Michael Sanders wrote:

1. lets say to set environmental variable I have:

PAGER=less ./tinybase -r <<'EOF'
...

2. now lets say to set environmental variable I have:

PAGER=less
./tinybase -r <<'EOF'
...

Case 1 always works while case 2 fails.

Remember that, in Bash and other similar shells, environment variables and shell variables are mostly the same thing (they share the same namespace), except the latter are not passed on to spawned processes.

Defining a variable:

A=1

defining a variable that will be passed on to spawned processes:

export A=1

or

A=1
export A

Then there is this additional construct where, if you say something like

A=1 -2cmd-+

then this defines a new environment variable A with the given value, that
is only seen by the process spawned by -2cmd-+. If A already has a value within the current shell context, that definition is unchanged.

There is another school of shells (csh/tcsh) which tries to keep the two
kinds of variables separate. So you use rCLsetenvrCY to explicitly set an environment variable, otherwise itrCOs just a shell variable.

These alternative shells donrCOt seem to be so popular any more.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 2025-11-08, Lawrence DrCOOliveiro <ldo@nz.invalid> wrote:

Remember that, in Bash and other similar shells, environment variables and shell variables are mostly the same thing (they share the same namespace),

Remember that in C, variables and typedef names are nearly the same
thing (they share the same namespace).

Constant mindless drivel out of this poster ...
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

2025-11-08 21:54 ldo@nz.invalid:

On Sat, 8 Nov 2025 15:04:53 -0000 (UTC), Michael Sanders wrote:

Then there is this additional construct where, if you say something like

A=1 -2cmd-+

then this defines a new environment variable A with the given value, that
is only seen by the process spawned by -2cmd-+. If A already has a value within the current shell context, that definition is unchanged.

What happens if we put a semicolon in there?

A=1; -2cmd-+
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On Sun, 09 Nov 2025 23:21:54 +0100, Mekeor Melire wrote:

2025-11-08 21:54 ldo@nz.invalid:

On Sat, 8 Nov 2025 15:04:53 -0000 (UTC), Michael Sanders wrote:

Then there is this additional construct where, if you say something like

A=1 -2cmd-+

then this defines a new environment variable A with the given value, that >> is only seen by the process spawned by -2cmd-+. If A already has a value
within the current shell context, that definition is unchanged.

What happens if we put a semicolon in there?

A=1; -2cmd-+

The shell treats that as two separate commands:
A=1
and, separately,
<<cmd>>

So, the shell variable A gets set to 1, and subsequently, the shell
runs <<cmd>>>. BUT, _unless_ we instruct (or have previously instructed)
the shell to "export" A (make it available as an environment variable
to processes launched by the shell), <<cmd>> will NOT be able to access
the value of A.

For example
# ensure that SOMEVAR is unused
$ unset SOMEVAR
$ echo $SOMEVAR

# Yes, SOMEVAR is unused

# See if SOMEVAR is a passed environment variable
$ printenv|grep SOMEVAR
# No, printenv doesnt see SOMEVAR in it's environment

# Set SOMEVAR, and see if printenv sees it
$ SOMEVAR=first ; printenv | grep SOMEVAR
# No, printenv didn't see SOMEVAR in it's environment

# Make sure that SOMEVAR is known to shell
$ echo $SOMEVAR
first
# Yes, shell knows the value of SOMEVAR

# ask shell to export SOMEVAR to the environment
$ export SOMEVAR

# Did the shell export SOMEVAR to the environment?
$ printenv | grep SOMEVAR
SOMEVAR=first
# Yes, SOMEVAR now represents an environment variable

# Lets change SOMEVAR and see if the new value propogates
$ SOMEVAR=second
$ printenv | grep SOMEVAR
SOMEVAR=second
$
# Yes, since we exported the shell variable SOMEVAR
# to the environment variable list, when the shell
# changes the value of SOMEVAR, the new value propogates
# forward into the environment variable list

HTH
--
Lew Pitcher
"In Skills We Trust"
Not LLM output - I'm just like this.
--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.unix.shell

On 09.11.2025 23:21, Mekeor Melire wrote:

2025-11-08 21:54 ldo@nz.invalid:

On Sat, 8 Nov 2025 15:04:53 -0000 (UTC), Michael Sanders wrote:

Then there is this additional construct where, if you say something like

A=1 -2cmd-+

then this defines a new environment variable A with the given value, that >> is only seen by the process spawned by -2cmd-+. If A already has a value
within the current shell context, that definition is unchanged.

What happens if we put a semicolon in there?

A=1; -2cmd-+

Assuming variable 'A' was *not* exported (by "export A")...

In the your first example A=1 is part of the command call and the
variable setting only visible in that command but not in the rest
of your script.
In your second example it is two commands. - Mind that a semicolon
acts like a <newline>! - So you define 'A' (whether intended or not)
for your script but (not in any invoked sub-command).

A="something"
...
A="something else" cmd # use 'A' as "something else" in cmd
...
# here A is again "something"

If you "export A" that variable will be passed down into subprocesses
(but *not* passed as the name might suggest to the outer processes).

Janis

--- Synchronet 3.21a-Linux NewsLink 1.2