| View previous topic :: View next topic |
| Author |
Message |
dataking
Apprentice
Joined: 20 Apr 2005
Posts: 251
|
 Posted: Thu Mar 14, 2013 2:41 am Post subject: Bash variable scope |
 |
|
Do bash variable have scope?
I found a script online that is supposed to do an automated gentoo build. It needs some modernization, in addition to personal preference tweaking. It creates a variable $HD_DEVICE which seems to persist through the partitioning and filesystem creation phases, but doesn't seem to be present or populated when it comes time to mount the actual drives.
When using:
| Code: |
mount /dev/${HD_DEVICE}3 /mnt/gentoo
mount /dev/${HD_DEVICE}1 /mnt/gentoo/boot
|
...in the script, I get:
| Code: |
mount: special device /dev/3 does not exist
mount: special device /dev/1 does not exist
|
I've tried using [ilms]export HD_DEVICE[/ilms], but that doesn't seem to work either.
*[ilms] means inline monospace, which should be a feature of the forums. 
_________________
-= the D@7@k|n& =- |
|
| Back to top |
|
 |
lexflex
Guru
Joined: 05 Mar 2006
Posts: 363
Location: the Netherlands
|
| Posted: Thu Mar 14, 2013 5:53 am Post subject: Re: Bash variable scope |
|
|
| dataking wrote: | | Do bash variable have scope? |
I am not sure what you mean by"automated gentoo build" , but it sounds a bit like it is performing the steps from the handbook for you.
User-defined variables are ony valid in the same session. So , if for example you need to be root to mount the devices, and the script uses su to change to root, they will not be valid anymore if they where define by a regular user in the first place.
This error is most probably an error in your "automated script".
(And, since there are no official installscripts, you might want to ask this to the builder of the script or look into the code of the script).
However, more in general I would say: just follow the handbook and not use a script, especially not one "found on the internet" without knowing what it does.
Alex. |
|
| Back to top |
|
|
John R. Graham
Administrator
Joined: 08 Mar 2005
Posts: 10589
Location: Somewhere over Atlanta, Georgia
|
| Posted: Thu Mar 14, 2013 3:47 pm Post subject: Re: Bash variable scope |
|
|
| dataking wrote: | | Do bash variable have scope? |
Yes. Several types. Here's an illustrative example:
| test11a.bash: | #!/bin/bash
MYVAR1=hello
MYVAR2=world
export MYVAR2
./test11b.bash |
| test11b.bash: | #!/bin/bash
myfunc1() {
MYVAR3=foo
}
myfunc2() {
local MYVAR4=bar
}
myfunc1
myfunc2
echo "MYVAR1 is \"$MYVAR1\"."
echo "MYVAR2 is \"$MYVAR2\"."
echo "MYVAR3 is \"$MYVAR3\"."
echo "MYVAR4 is \"$MYVAR4\"." |
| Code: | ~ $ ./test11a.bash
MYVAR1 is "".
MYVAR2 is "world".
MYVAR3 is "foo".
MYVAR4 is "". |
Without seeing your script, I'm not sure where your issue is.
- John
_________________
I can confirm that I have received between 0 and 499 National Security Letters. |
|
| Back to top |
|
|
dataking
Apprentice
Joined: 20 Apr 2005
Posts: 251
|
| Posted: Thu Mar 14, 2013 4:35 pm Post subject: Re: Bash variable scope |
|
|
| lexflex wrote: | | dataking wrote: | | Do bash variable have scope? |
I am not sure what you mean by"automated gentoo build" , but it sounds a bit like it is performing the steps from the handbook for you.
|
This is more or less exactly the case.
| lexflex wrote: |
User-defined variables are only valid in the same session. So , if for example you need to be root to mount the devices, and the script uses su to change to root, they will not be valid anymore if they where define by a regular user in the first place.
|
The script is run as root, and the variable is defined in the script without any references to su or sudo, etc.
| lexflex wrote: |
This error is most probably an error in your "automated script".
(And, since there are no official installscripts, you might want to ask this to the builder of the script or look into the code of the script).
|
The original author of the script has presumably "moved on". The script was presented in such a way that it was more a demonstration or proof of concept, rather than something to be maintained. (It's using a stage3 image from 2008).
| lexflex wrote: |
However, more in general I would say: just follow the handbook and not use a script, especially not one "found on the internet" without knowing what it does.
Alex. |
I am fairly competent at following the Handbook, as I have done it numerous times. But I had thought to myself that most (if not all) of the steps could be automated, in a script, and wasn't quite sure how to handle the chroot stuff. This script showed me one way to handle it, and, for the most part, seems to work pretty well. I am also fairly competent at bash (and other languages) scripting, which is why I posed the question. I know perl has scope, in that, if I create/instantiate a variable within a code block, it will not be available elsewhere in the perl script (unless I'm being sloppy and not using use strict; and my).
So, maybe you can understand why I was confused when HD_DEVICES is initialized in an early section of the script, allowing fdisk and mke2fs to partition the drive and create the file systems, yet, when it comes time to mount the created filesystems as:
| Code: | | mount /dev/${HD_DEVICE}3 /mnt/gentoo |
and the result is | Code: | | mount /dev/3 /mnt/gentoo |
.
Basically, yes, the script was "found on the internet", but I can read it well enough to know what it does.
_________________
-= the D@7@k|n& =- |
|
| Back to top |
|
|
dataking
Apprentice
Joined: 20 Apr 2005
Posts: 251
|
| Posted: Thu Mar 14, 2013 4:46 pm Post subject: Re: Bash variable scope |
|
|
| John R. Graham wrote: | | dataking wrote: | | Do bash variable have scope? |
Yes. Several types. Here's an illustrative example:
| test11a.bash: | #!/bin/bash
MYVAR1=hello
MYVAR2=world
export MYVAR2
./test11b.bash |
| test11b.bash: | #!/bin/bash
myfunc1() {
MYVAR3=foo
}
myfunc2() {
local MYVAR4=bar
}
myfunc1
myfunc2
echo "MYVAR1 is \"$MYVAR1\"."
echo "MYVAR2 is \"$MYVAR2\"."
echo "MYVAR3 is \"$MYVAR3\"."
echo "MYVAR4 is \"$MYVAR4\"." |
| Code: | ~ $ ./test11a.bash
MYVAR1 is "".
MYVAR2 is "world".
MYVAR3 is "foo".
MYVAR4 is "". |
Without seeing your script, I'm not sure where your issue is.
- John |
TYVM for the illustrative example(s). You've confirmed what I thought I knew about bash variable scope.
The original script is here. My updated version is here.
I know that, if the initial sections are skipped, that the variable isn't instantiated and would fail at the "crumbs/stage3.done" part. However, it fails at that part even when the initial sections are run, and I'm confused as to why.
_________________
-= the D@7@k|n& =- |
|
| Back to top |
|
|
lexflex
Guru
Joined: 05 Mar 2006
Posts: 363
Location: the Netherlands
|
| Posted: Thu Mar 14, 2013 6:19 pm Post subject: Re: Bash variable scope |
|
|
Hi Dataking,
Confusion was at my side since it is more of a general 'bash' question but since it relates to this very specific script used to automate the handbook, it looked to me like it was more of an 'installation' question...
| dataking wrote: |
Basically, yes, the script was "found on the internet", but I can read it well enough to know what it does. |
Sorry, I was not my intention to suggest that you might not be able to read it, just that following large scripts not written by oneself might take time 
A. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9526
Location: beyond the rim
|
| Posted: Fri Mar 15, 2013 2:29 pm Post subject: |
|
|
There are a couple serious problems in your script:
- tracking state in the current directory without any sanity checks or cleanup
- changing the working directory, which in combination of the first point will break stuff for sure
- `echo ${HD_DEVICE} >> .harddrive` will append the variable content to the file, which will certainly break commands using it later
- no check that HD_DEVICE or HDD actually point to a valid block device
- some of your chroot commands won't work at all and/or do very wrong things
- basically no error checking at all
Now for your actual error, that should work as far as I can see in your script (there aren't any scoping issues here at all), but with all the other issues above I recommend you just scrap that script altogether. I know that sounds harsh, but in this state it's really the best thing to do.
When writing system-level bash scripts you really need not only to understand bash syntax, but also know a lot of all the commands you use and quite a bit about process invocation, parameter expansion and a number of other semantic aspects. Even more so if that script will be run with root priviledges. |
|
| Back to top |
|
|
dataking
Apprentice
Joined: 20 Apr 2005
Posts: 251
|
| Posted: Fri Mar 15, 2013 6:42 pm Post subject: |
|
|
Great feedback. Thanks, I think.
A couple of things to keep in mind:
- I consider the original script (linked above) to be a proof of concept and only that.
- My modernization and updates are a work in progress, not a finished product.
- I'm also not guaranteeing that my modified script will work for anyone else. I'm just trying to make it work for me.
| Genone wrote: | There are a couple serious problems in your script:
- tracking state in the current directory without any sanity checks or cleanup
|
Not sure what you mean here. Line numbers and/or code examples would be great.
| Genone wrote: |
- changing the working directory, which in combination of the first point will break stuff for sure
|
I found this, and I think I fixed it, almost to excess.
| Genone wrote: |
- `echo ${HD_DEVICE} >> .harddrive` will append the variable content to the file, which will certainly break commands using it later
|
Semantics really, but you have a point. Remember this is meant to be run from the live CD, so any and all files, including the script itself, will disappear upon reboot.
| Genone wrote: |
- no check that HD_DEVICE or HDD actually point to a valid block device
|
Something to look into.....
| Genone wrote: |
- some of your chroot commands won't work at all and/or do very wrong things
|
Which ones? Again, line numbers and/or code samples would be helpful.
| Genone wrote: |
- basically no error checking at all
|
Again, it's a work-in-progress. I've added some error checking, but probably not as much as you might like to see, and probably not as much as should be there, but some.
| Genone wrote: |
Now for your actual error, that should work as far as I can see in your script (there aren't any scoping issues here at all), but with all the other issues above I recommend you just scrap that script altogether. I know that sounds harsh, but in this state it's really the best thing to do.
|
I would rather fix the issues, than scrap the script. I build a lot of VMs and this would save me a lot of time, if I can get it working (which it does, more or less, in its current state).
| Genone wrote: |
When writing system-level bash scripts you really need not only to understand bash syntax, but also know a lot of all the commands you use and quite a bit about process invocation, parameter expansion and a number of other semantic aspects. Even more so if that script will be run with root priviledges. |
I like to think I have a pretty good understanding of bash syntax and general tools (grep/awk/sed/etc.). Originally, I was confused because the variables I was using seemed to be out of scope, given what I understood about bash scripting in general. I'm not a complete newb when it comes to scripting, but I'm not a master either. I've been in the IT industry for about 15 years, and the beginning of that career was dealing exclusively in UNIX/Linux, so I would say, I'm quite rusty. I'm always open to constructive criticism and if you would be willing to take the time to point out the specifics of the points you make above, I'd be happy to do what I can to fix the issues.
Here's the updated script, maybe some of the things you point out have been addressed. Maybe not. There are still some things that need to be added (like hostname addition/creation). As it stands, it builds a functional gentoo system. I'm also working on a post install script to bring it the rest of the way. We'll see how that goes.
_________________
-= the D@7@k|n& =- |
|
| Back to top |
|
|
nix213
n00b
Joined: 08 Feb 2013
Posts: 23
Location: Illinois
|
| Posted: Sat Mar 16, 2013 1:29 pm Post subject: |
|
|
in your script, line 70 is commented out:
_________________
"Wherever you go, go with all your heart." -Confucius |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 9526
Location: beyond the rim
|
| Posted: Mon Mar 18, 2013 7:39 am Post subject: |
|
|
| dataking wrote: | | Genone wrote: | There are a couple serious problems in your script:
- tracking state in the current directory without any sanity checks or cleanup
|
Not sure what you mean here. Line numbers and/or code examples would be great. |
Any line that references a relative path, e.g. `touch crumbs/partitions.done`. I understand that you assume this script will only run in a well defined environment, but such assumptions tend to become invalid over time, so it's always better to define directories explicitly, e.g. `touch ${STATE_DIR}/partitions.done`.
| Quote: | | Genone wrote: |
- `echo ${HD_DEVICE} >> .harddrive` will append the variable content to the file, which will certainly break commands using it later
|
Semantics really, but you have a point. Remember this is meant to be run from the live CD, so any and all files, including the script itself, will disappear upon reboot. |
Assuming the script will only run once per session. See above about assumptions.
| Quote: | | Genone wrote: |
- some of your chroot commands won't work at all and/or do very wrong things
|
Which ones? Again, line numbers and/or code samples would be helpful. |
E.g. `chroot /mnt/gentoo echo "US/Pacific" >> /etc/timezone` will modify /etc/timezone in your host environment, not in your chroot. Thought there were more but can't see them atm. |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
