Autor |
Nachricht |
|
Titel: Silly bash export command problem.
Verfasst am: 25.11.2006, 01:27 Uhr
|
|
Anmeldung: 05. Nov 2006
Beiträge: 5
|
|
Hi,
May I ask forum a stupid question even if it is not related to Kanotix? I have not done much bash scripting and using export is new to me and it drives me crazy! If "anything goes" here maybe someone can help? It is so simple.
I am running Kanotix as root and I have a bash script "export.sh" that is almost nothing:
#!/bin/bash
export var1="1234567"
Testing it:
Start with making var1 global as an empty string by export from command line.
root@martin:~/vnuml/tests/t1# export var1=""
Run the script
root@martin:~/vnuml/tests/t1# ./export.sh
See what's in var1:
root@martin:~/vnuml/tests/t1# echo "$var1"
Nothing..
Export var1 from command line:
root@martin:~/vnuml/tests/t1# export var1="1234567"
See what's in:
root@martin:~/vnuml/tests/t1# echo "$var1"
1234567
As expected!
But why can't var1 get a value when using export from the script? I must have missed something fundamental!!
Thanks if you have patience to educate me.
/koia |
|
|
|
|
|
|
Titel: RE: Silly bash export command problem.
Verfasst am: 25.11.2006, 02:22 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
I'm guessing, but from here:
http://www.ss64.com/bash/export.html
key is:
Set an environment variable. Mark each name to be passed to child processes in the environment.
so I think if you create script two, and call it after the first step:
root@martin:~/vnuml/tests/t1# export var1=""
#!/bin/bash
export var1="1234567"
some_script.sh
and this is some_script.sh
#!/bin/bash
echo $var1
I'm going to guess that it will echo what you expect, since it's a child process.
In the first example, it's echoing blank value, and there is no childprocess, so I'd guess that's a default behavior of some type for export. |
_________________ Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
|
|
|
|
|
Titel: RE: Silly bash export command problem.
Verfasst am: 25.11.2006, 09:48 Uhr
|
|
Anmeldung: 17. Dez 2003
Beiträge: 16790
|
|
You have to source your script:
. scriptname
or bash only:
source scriptname |
|
|
|
|
|
|
Titel:
Verfasst am: 25.11.2006, 11:29 Uhr
|
|
Anmeldung: 05. Nov 2006
Beiträge: 5
|
|
Kano, thanks a lot!!
For those playing in the same backyard as I do:
With script export.sh as
#!/bin/sh
export var1="1234567"
i get
root@martin:~#. export.sh
root@martin:~# echo "$var1"
1234567
And with a scipt import.sh
#!/bin/sh
echo "imported variable $var1"
i get
root@martin:~#. import.sh
imported variable 1234567
And finally with a script export_import.sh
#!/bin/sh
. export.sh
. import.sh
I get
root@martin:~# . export_import.sh
imported variable 1234567
root@martin:~# echo "$var1"
1234567
after having done export var1="" a couple of times in between whereever needed.
I see that I have to learn essentials about processes, variable scope, menaing of "." etc.. For instance, the export command is said to work through CHILD PROCESSES, but where in the process tree is then my ". export.sh" executed and where is "echo "$var1"" executed. Where are the parents and where are the childs?
And finally, like in the case of export_import.sh script, both functions . export.sh and . import.sh, seems to run on the same "level" in the process tree and import.sh seems not to be a child of export.sh.
So why does this actually work?
There are thousands of authors on the web re-writing about simple things like "if, then else..." that noone actually needs much of. But I have not seen good explanations of the more difficult things like how this actually works.
Has anyone possibly a good source on this information?
Regards, Ingmar |
|
|
|
|
|
|
Titel:
Verfasst am: 25.11.2006, 20:34 Uhr
|
|
Anmeldung: 12. Mar 2005
Beiträge: 1005
|
|
<<< So why does this actually work? >>>
bash is one of the least logical programming languages I've seen, to be honest. While it's fun learning how to work with it, that fun for me comes from learning how to do things in extremely random and unpredictable ways, and to protect against extremely random and unpredictable outcomes.
While learning enough bash to do my du-fixes script, I came across oddities that simply do not make ANY sense in terms of logical program flow, so I used tricks to bypass these oddities once I realized that I couldn't solve the problems any other way.
But that's bash, it's also a very powerful language for the areas its strong in, and it comes out of a very old system, so I think it carries a whole lot of legacy thinking in it, old ideas that is.
For any serious programming type activity, shell scripting would be my last choice I think currently, it's not made for it, better to use something like perl or python [although I'm not going to accuse perl of being particularly logical either]
I think if I wanted to make a real program, I'd learn python, a modern language that is designed to make sense to the programmers who wrote it, a language built by and for programmers, that is. Not a glue language, not a way to work around strange behaviors etc, not a way to get the most efficient execution, but a way to get the desired outcome as cleanly and as quickly as possible. That's why the early google stuff, for example, in many parts was done in python. |
_________________ Read more on dist-upgrades using du-fixes-h2.sh script.
New: rdiff-backup script
|
|
|
|
|
|
|
|
|
|