Variable for the whole session

[arivas_2005]

My greeting
I want to create a variable in a script and leave it defined to be able to deposit data and rescue it in another script:
If in script1 I do

Code: Select all

MOMENT1 = `# date" +% H% m% s "`

(instead of for example date "+% H% m% s"> /tmp/tmpfile)
in another script, at another time after I can retrieve that data
So in If in script2 I do

Code: Select all

echo "$ MOMENT1"

and I get the data saved before in the first script. Even if it's already closed
As with the LANG variable
echo $ LANG
that its data can be extracted from any script
I already experimented with

Code: Select all

export MOMENT1 = `# date" +% H% m% s "`
global MOMENT1 = `# date" +% H% m% s "`
set MOMENT1 = `# date" +% H% m% s "`

but I close the script and execute another one with

Code: Select all

echo "$ MOMENT1" 

and nothing.
Thanks

[taersh]

MOMENT1 = `# date" +% H% m% s "`

This is complete NONSENSES!
Lots of wrong spaces and wrong double quotes.

This will return date:

Code: Select all

MOMENT1=`date +%H:%M:%S`

Or even:

Code: Select all

MOMENT1=`date +%H-%M-%S`

And this will echo the content of MOMENT1

Code: Select all

echo $MOMENT1

And $LANG is a global environment variable defined in /etc/profile.

Code: Select all

LANG=de_DE.UTF-8
export LANG

Since it is EXPORTED and defined at boot process it's global available.

[williams2]

There is nothing wrong with using a file to store data which can be shared with other programs.

It may be crude, but it can be very effective.
A named pipe is really just a file that programs can read and write to.

If you are afraid that someone will criticize it, you can put in a comment something like,
# crude but effective.

Using a file to allow programs to communicate is simple and it is likely that you can write the code quickly, easily, correctly, without needing to read the manual.

For example:

Code: Select all

# echo MOMENT1=$(date +%H-%M-%S) >> /tmp/moment.tmp
# source /tmp/moment.tmp
# echo $MOMENT1 
19-10-07
#

A feature of source, is that you can put a file to be sourced in the PATH, so you don't need to include the path.
For example, you can put "cd /mnt/home/movies" in a file named "m" in /root/my-applications/bin/ and typing
. m
should execute the commands in the file /root/my-applications/bin/m

[wiak]

And $LANG is a global environment variable defined in /etc/profile.

Code: Select all

LANG=de_DE.UTF-8
export LANG

Since it is EXPORTED and defined at boot process it's global available.

But you are not explaining to the original poster 'why' LANG remains available after /etc/profile code lines complete, and 'why' MOMENT1 does not remain available after its export in OP's script.

[wiak]

I'll leave explanation to taersh for the above.

But here is something to try. It is a bit fake... once you work out what it is doing...

Code: Select all

#! /bin/bash
export MOMENT1=$(date +%H-%M-%S)
exec $SHELL -i

Then run your new script in resultant shell and MOMENT1 should be available to it...

or simply enter:

Code: Select all

echo $MOMENT1

wiak

[taersh]

And $LANG is a global environment variable defined in /etc/profile.

Code: Select all

LANG=de_DE.UTF-8
export LANG

Since it is EXPORTED and defined at boot process it's global available.

But you are not explaining to the original poster 'why' LANG remains available after /etc/profile code lines complete, and 'why' MOMENT1 does not remain available after its export in OP's script.

I can't explain exactly why, since I'm NOT a native English speaking person and I'm not that much of an expert.
But from my experience everything being exported at the boot process (like it is done in /etc/profile) remains available as global environment variable. I think it's because the execution of e.g. /etc/profile is never really exited/left behind until reboot/shutdown. An average script executed by a user after X is running won't/can't do this.

[wiak]

From man bash:

When bash is invoked as an interactive login shell, or as a non-interactive shell with the --login option, it first reads and executes commands from the file /etc/profile, if that file exists. After reading that file, it looks for ~/.bash_profile, ~/.bash_login, and ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable.

So, on boot init spawns a login shell which, when using bash, sources the lines from /etc/profile which sets some of the startup environmental variables. Note that it can be arranged for other files to also be sourced at that time (e.g. PAM system also uses /etc/environment I think. EDIT: Yep. https://wiki.debian.org/EnvironmentVariables).

When any parent process starts a child process (e.g. a script), that child inherits only a 'copy' of the parents environment. So changes made in child version are not reflected back to the parent so when child process ends the parent version remains as it was before.

Note that /etc/profile is not a script, it is part of the parent (since sourced) so it doesn't create its environment variables as a child process (otherwise, if child process ends its environment also dies).

Note that all processes have their own environment. You can look at their environment as follows (it is in /proc filesystem). For example, for process ID 1 (PID1 being the init process, which could be busybox init, systemd or whatever used) :

Code: Select all

sed 's:\x0:\n:g' /proc/1/environ

Above, for example, includes variables passed in as arguments on kernel boot line (using say grub).

If you have, say, a process 594 running (e.g. I check with ps aux, or with LxTask on my system) you can see the environment with:

Code: Select all

sed 's:\x0:\n:g' /proc/594/environ

wiak

[arivas_2005]

Thanks for the explanation of how the processes and variables work.
Possibly insist on something not possible.
I want to save a data in a variable (and not in a file) to share it with other scripts during and after the variable with the data is declared, in the same session.
Example:
in script 1

declare -a MOMENT1=`date +%H:%M:%S`
or ------
declare -a MOMENT2
MOMENT2=`date +%H:%M:%S`
( to substitute: echo "$MOMENT1">/tmp/timetempo

then in other subsequent scripts:

echo "$MOMENT1"
echo "$MOMENT2"

( to substitute: MOMENT1=`cat /tmp/timetempo `)
that is is my "kid" for this mement ! .
Thanks again for the help.

[wiak]

Thanks for the explanation of how the processes and variables work.
Possibly insist on something not possible.
I want to save a data in a variable (and not in a file) to share it with other scripts during and after the variable with the data is declared, in the same session.

Yes, that is the problem (and one many of us have had), what you want, if I understand you correctly, is not possible, other than by mechanisms such as williams suggested. i.e. by using a temporary file, an approach I have also used often to get round this issue. Note that /tmp is in RAM on Puppy so putting the file in there is fast and does not require read/write to external disc media.

My post above tries to show why it is not possible to do exactly what you'd like:

THE SLIGHTLY GOOD NEWS (regarding passing parent values to child)
In the first script, when you set MOMENT1 with the date, that value will then be available to the rest of that first script.

If you export it (export MOMENT1) that date value will become available to any 'child' processes/scripts started by that 'parent' script. That would include any script started from within that first parent script, and for that scenario all will be well; these 'children' scripts will all receive the date value (e.g. as shown by echo $MOMENT1). That works because the child processes of a parent process all receive/inherit a 'copy' of the parent process's environment (including exported variable contents such as for MOMENT1).

THE BAD NEWS (regarding passing child values to parent)
However, that first script has itself a 'parent', which is the shell you started it from. Let's say you originally actually exported MOMENT1 at that shell commandline and then started your first script. Your first script would inherit a copy of that shell's MOMENT1 variable, but it is only a copy. So when your script modifies its contents by giving it the `date` value, the original parent shell cannot know about that (its environment MOMENT1 variable is separate and remains as it was). Hence when you exit your first script, that script process environment dies (is lost) too. So when you start your second script, it once again only receives a copy of the shell's environment (including the shell's variable MOMENT1, which does not contain any date value...) - it cannot receive a copy in this case of what was the environment used by your first script (that has already been lost).

SUMMARY
All processes have their own separate environment (whether or not you use same variable name in them). Child processes, when started by a parent process, only inherit a 'copy' of the parent process's environment (even though the variable names used remain the same they are actually separate variables in system memory). When children (processes) die there is no inherent mechanism to pass back the contents of a child's environment to its parent (i.e. it is a one way street - environments are inherited by children, not the other way round). But... you can do what you want using certain workarounds such as getting the child to write its environment variable values of interest to an external file (such as /tmp/var1) and getting the parent (shell) to read the new value from that file...

[taersh]

i.e. by using a temporary file

I have used this and am still using this method for various tasks. It's easy to handle and the difference between to execute the "echo"/"read" commands into/from a file and doing it in RAM isn't even noticeable - at least for human beings and in case it's not thousands of lines.

[puppy_apprentice]

You can store your variable in clipboard:

In one bash session:

Code: Select all

echo "Variable in clipboard" | xclip

In new bash session:

Code: Select all

clipboard="$(xclip -o)"
echo $clipboard

[wiak]

You can store your variable in clipboard:

Good answer - and xclip clipboard is stored in memory (not a outside memory file)

However, xclip actually has three different buffers for different key-combinations/uses (see man xclip): primary, secondary, and clipboard. The "clipboard" here is not the name of a variable so maybe best to amend your answer to avoid that confusion.

e.g.

Code: Select all

anyvariable="whatever rubbish"
echo "$anyvariable" | xclip  # which, by default using primary buffer

then, later:

Code: Select all

anyvariable="$(xclip -o)"

Note:

1. that you can avoid the pipe: echo "$anyvariable" | xclip (which uses a child subshell) by using a bash here-string (<<<) as follows:

Code: Select all

<<<"$anyvariable" xclip

2. Above uses primary xclip store. You can use either of the other two (secondary or clipboard) as alternatives. For example:

Code: Select all

<<<"$anyvariable" xclip -selection secondary

# or alternatively use -selection clipboard

then later:

Code: Select all

anyvariable="$(xclip -o -select secondary)"

wiak

[mikewalsh]

There is nothing wrong with using a file to store data which can be shared with other programs.

It may be crude, but it can be very effective.
A named pipe is really just a file that programs can read and write to.

If you are afraid that someone will criticize it, you can put in a comment something like,
# crude but effective.

Using a file to allow programs to communicate is simple and it is likely that you can write the code quickly, easily, correctly, without needing to read the manual.

For example:

Code: Select all

# echo MOMENT1=$(date +%H-%M-%S) >> /tmp/moment.tmp
# source /tmp/moment.tmp
# echo $MOMENT1 
19-10-07
#

A feature of source, is that you can put a file to be sourced in the PATH, so you don't need to include the path.
For example, you can put "cd /mnt/home/movies" in a file named "m" in /root/my-applications/bin/ and typing
. m
should execute the commands in the file /root/my-applications/bin/m

I would think - if we're perfectly honest as a community, and with ourselves! - that the shell scripting we use for quick 'dodges', 'workarounds' & 'shortcuts', etc, in our own OSs, on our own machines, often IS a lot "cruder" than scripting we release for public consumption by others. Much of the 'quick'n'dirty' stuff I use myself is really 'shonky' .....but it gets the job done, and as far as I'm concerned, it achieves the end result I'm after.

Bash is, to me, like any other language.....there's a lot of different ways of arriving at the same outcome.

Mike.

[misko_2083]

My greeting
I want to create a variable in a script and leave it defined to be able to deposit data and rescue it in another script:

you have script1.sh

Code: Select all

#!/bin/bash

export VAR=X

and script2.sh

Code: Select all

#!/bin/bash

echo "${VAR}"

This will not work:

Code: Select all

./script1.sh
./script2.sh

because the script1 is opened in a subshell and script2 is opened in another subshell.

This will:

Code: Select all

. script1.sh
./script2.sh
X

because script1 is opened in a current shell and the variable VAR is exported.

To understand what's going on, if you run script1 in a current shell you can access the variable:

Code: Select all

. script1.sh
echo ${VAR}
X

As long as the terminal is open and the shell is alive, that variable will be there.
If the variable is not exported in the script1, the script2 can use the variable if it's started in the same shell.

Code: Select all

. script1.sh
. script2.sh
X

Let's reopen the terminal and, say, declare a variable VAR in the current shell and try to access it in a subshell and current shell.

Code: Select all

VAR=1
./script2.sh
. script2.sh
1

Now let's open a subshell and try to access VAR.

Code: Select all

VAR=1          # Declare a variable

bash                       # Open a subshell
. script2.sh             # Run script2 in a current shell
./script2.sh             # Run script2 in a subshell
exit                         # exit subshell

. script2.sh            # Now it works
1

When exporting a variable it's exposed to the subshells

Code: Select all

export VAR=1          # Declare a variable

bash                       # Open a subshell
. script2.sh             # Run script2 in a current shell
1
./script2.sh             # Run script2 in a subshell
1
exit                         # exit subshell

. script2.sh
1
./script2.sh
1

But variables live as long as the shell lives.
To keep the variables after the shell is closed or terminal dies, they need to be stored in a file.
And then the variables are imported in a current shell.

Code: Select all

cat vars
VAR=2

. vars
echo ${VAR}
2

The temp file method you already know:

Code: Select all

tmp="$(mktemp -p /tmp)"
echo "VAR=3" > $tmp
. $tmp
echo ${VAR}
3

On a side note, the file can be in RAM also.

Code: Select all

ramtmp="$(mktemp -p /dev/shm/)"
echo "VAR=3" > $ramtmp
. $ramtmp
echo ${VAR}
3

Shared memory is a method of inter-process communication (IPC),
i.e. a way of exchanging data between programs running at the same time.
One process will create an area in RAM which other processes can access;
/dev/shm is used only when you need a performance boost, when your apps require high I/O bandwidth.
Remember that /tmp can be part of the / filesystem instead of a separate mount, and hence can grow as required.
The size of /dev/shm is limited by excess RAM on the system, and hence you're more likely to run out of space on this filesystem.
Shm is not standard on all distros.
In practice should never use /dev/shm,
unless the file is very small and you have enough RAM and swap, and you want to minimize disk i/o.
It's almost always preferable to use /tmp instead.

[wiak]

Shared memory is a method of inter-process communication (IPC),
i.e. a way of exchanging data between programs running at the same time.
One process will create an area in RAM which other processes can access;

Funny that you should mention that, which reminds me:

Long ago (2007/2008) I wrote an IPC system-level utility (in C) for accessing the likes of message queues and sockets directly from shell scripts (since shell does not itself provide such access other than fifo). Unfortunately, back then a competent Puppy dev copied my idea into a well-known Puppy system facility of the time but took the credit for the idea to himself (i.e. no acknowledgement provided). Disgraceful behaviour, typical of some even nowadays, but never mind... Nevertheless, I was not happy and as a result I discontinued publishing any later developments of that facility. However, I managed to find an old version which I have attached since it can also allow the passing of messages between subshells and parents. The version attached is called wiakmv (the larger version was simply called 'wiak' being named after my family firstnames - copied that naming idea from A.W.K.).

Usage:

I've created two scripts, script1 and script2 (attached) with the relevant wiakmv commands in them (using System V message queue here). Simply remove the dummy tar, make them executable, and then run them one after the other with separate commands:

Code: Select all

./script1
./script2

For other test you can simply run wiakmv at the commandline. For example:

Code: Select all

./wiakmv -z 4567 -s "hello world"

./wiakmv --zid 4567 --receive stdout

I used to use 'wiak' (and wiakmv) to produce simple client/server bash programs to help separate GUI from its control functionality (very efficient since wiakmv blocks when listening and only runs for a few microseconds when sending). Being a universal IPC client a practical usage was for controlling either gtkdialog or gtk-server, such as I gave an example for at following old forum link:

murga-linux.com/puppy/viewtopic.php?p=572489&sid=56b4d66099c9b3d3c0784d6a59b12b3c#572489

Note that you'll need to make that http for it to work, but I'm worried about something rockedge said about http links wrecking his forum!

Note that, despite fourteen years having gone by, I do not forget and have not forgiven the developer that used my ideas and did not give due credit. I will not therefore be resurrecting wiak or wiakmv further, but couldn't resist showing how IPC can indeed be used (no shared memory here though). I've attached the associated wiak program readme, that also includes a human readable form of its man page for those who wish to experiment with it further (only the 64bit version of wiakmv attached). All attached files need the dummy .tar removed...

Furthermore, in case anyone is interested in the C source code for old copy of earlier full wiak program, which in the non-acknowledged circumstances, will probably be the last 'wiak' program published by myself, you should be able to read it directly at gitlab link below:

https://gitlab.com/weedoglinux/wiak/-/b ... ter/wiak.c

and its header file at:

https://gitlab.com/weedoglinux/wiak/-/b ... appswiak.h

wiak

[puppy_apprentice]

murga-linux.com/puppy/viewtopic.php?p=572489&sid=56b4d66099c9b3d3c0784d6a59b12b3c#572489

Note that you'll need to make that http for it to work, but I'm worried about something rockedge said about http links wrecking his forum!

I think that it is only a problem with url putted inside eg. [img] or [media] tags.
Url with http:// prefix putted inside [url] tag didn't remove padlock from browser url field.

[misko_2083]

Shared memory is a method of inter-process communication (IPC),
i.e. a way of exchanging data between programs running at the same time.
One process will create an area in RAM which other processes can access;

Funny that you should mention that, which reminds me:

Long ago (2007/2008) I wrote an IPC system-level utility (in C) for accessing the likes of message queues and sockets directly from shell scripts (since shell does not itself provide such access other than fifo).

This is great.
I can already imagine all the use cases.
I can transfer the variables from one terminal to the next.

Code: Select all

# terminal1
./wiakmv -z 4567 -s "VAR[0]=HELLO; VAR[1]=WORLD"
# terminal2
eval $(./wiakmv -z 4567 --receive stdout)
echo ${VAR[*]}
HELLO WORLD

or with yad

Code: Select all

./wiakmv -z 4567 --receive stdout | yad --form --field "" --cycle-read &
./wiakmv -z 4567 -s "HELLO WORLD"

It's so easy.
The first client in line with the same key get's the message.

Code: Select all

./wiakmv -z 4567 --receive stdout | yad --form --field "" --cycle-read &
./wiakmv -z 4567 --receive stdout | yad --form --field "" --cycle-read &
./wiakmv -z 4567 -s "HELLO WORLD"

Thanks for making wiak and readme.txt is very well written.

By the way, I found the source code for wiakmv and wiakf 2.0.3.
It was picked up by the search web search engine once you published the code on github.

Unfortunately, back then a competent Puppy dev copied my idea into a well-known Puppy system facility of the time but took the credit for the idea to himself (i.e. no acknowledgement provided). Disgraceful behaviour, typical of some even nowadays, but never mind... Nevertheless, I was not happy and as a result I discontinued publishing any later developments of that facility.

Sorry to hear that. Similar happened to me. He just added a few features and removed me from copyright. https://www.linux-apps.com/p/1239435/
The old radio script that inspired @fredx181 to make yradio https://github.com/fredx181/yradio
But there is his e-mail in the header.
I e-mailed him thanks for keeping my PMRP script alive.
And got a reply:

I thought it what's a good app to start with I just wanted to add a few more features LOL simple GUI to go with it you can do anything you want with it I have other projects and the works and yes it does need a newer version of Yad to work correctly also a few patches of Yad works well with mate but not KDE as far as the notification icon goes still some more improvements can be made on it I just haven't got around to it lately

This was last year. We did some home remodeling and I have completely forgot about it.
When you mentioned your old feud it all came back to me.
I just replied:

Thanks for giving me the permission to do anything I want with it.
Maybe I can add my name back to the copyright of that script.

[wiak]

By the way, I found the source code for wiakmv and wiakf 2.0.3.
It was picked up by the search web search engine once you published the code on github.

Happy to hear that. I could only find binary of wiakmv - I do remember there were other little 'wiak' programs but only had source for the bigger all-inclusive wiak (though that does contain all the source-code detail for all of course).

EDIT: Thanks (greatly). I just did a quick google search for "wiakmv github" and it came up with https://github.com/wiake/wiakapps
Nowadays I always use weedoglinux/firstrib related alternatives - forgot altogether I once used "wiake" there! The simpler 'wiak' name wasn't available I now remember. Alas I have no idea now what github password I used to access that - was four years ago it seems. No password I use nowadays works - but doesn't matter - it can serve as an archive unless I stumble upon entry pass in which case I'll move the project 'repo' to weedoglinux git site. Nevertheless I'll see if a password reset to whatever email I declared back then works - depends... four years is a long time in my email address chop and changing and as for passwords - basically I am a bit disorganised in these matters... I actually found the few 'wiak' program bits and pieces I still had on an old usb stick in a box... but was annoyed to find no wiakapps scripts (not that they were themselves very good anyway...). Anyway, a lot of how I described the whole wiakapps thing was a lot of junk back them - embarrassing to read most of it now!!! But I guess I thought 'wiak' was a good idea generally (and I couldn't recreate it now without a lot of re-learning of what I once knew quite fluently).

As for the "internet radio" situation you described. Really, the casual attitude of some developers in terms of credit where credit is due is painful at times (very painful indeed to the developer who put in the countless hours in their original work/design - it is always relatively easy for others to make derivatives thereafter... even worse if variable names are changed, which has the effect of obscuring the original source (or indeed simply translating the original into another programming language). Really there is no excuse for it to my ears - taking any credit for any creative work of another is unacceptable, so sorry to hear about that. Yeah, I never forget a person that does that to me.