Differences between revisions 14 and 15
Revision 14 as of 2013-10-15 10:16:27
Size: 3484
Comment: remove extraneous backticks from previous edit
Revision 15 as of 2013-12-05 04:16:13
Size: 3972
Editor: Chandra
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Q: I would like to cover bash in a course I will soon be teaching. May I use these materials for my course,
provided the source is cited? Thanks for this excellent work, btw.
Q: I would like to cover bash in a course I will soon be teaching. May I use these materials for my course, provided the source is cited? Thanks for this excellent work, btw.
Line 8: Line 7:
Q. The following suggestion can be harmful:
echo 'PATH="$HOME/bin:$PATH"' >> "$HOME/.bashrc"
If someone places a script named 'ls' in the bin directory of $HOME, you would be running it every time you typed 'ls', instead of running the builtin 'ls'. This can be harmful.
I suggest
echo 'PATH="$PATH:$HOME/bin"' >> "$HOME/.bashrc"
Q. The following suggestion can be harmful: echo 'PATH="$HOME/bin:$PATH"' >> "$HOME/.bashrc" If someone places a script named 'ls' in the bin directory of $HOME, you would be running it every time you typed 'ls', instead of running the builtin 'ls'. This can be harmful. I suggest echo 'PATH="$PATH:$HOME/bin"' >> "$HOME/.bashrc"
Line 26: Line 21:

From `man bash`, ''Referencing an array variable without a subscript is equivalent to referencing the array with a subscript of 0.'' If the first array element is empty (or unset?), that should imply that the array itself is empty and that the glob pattern failed to match any files. I've done a few tests locally and it seems to work fine for me - though there may be some edge cases that I haven't considered. - [[AnthonyGeoghegan]]
From `man bash`, ''Referencing an array variable without a subscript is equivalent to referencing the array with a subscript of 0.'' If the first array element is empty (or unset?), that should imply that the array itself is empty and that the glob pattern failed to match any files. I've done a few tests locally and it seems to work fine for me - though there may be some edge cases that I haven't considered. - AnthonyGeoghegan
Line 31: Line 25:
The above test only works if `shopt -s nullglob` is set. If it is not set (it's not set by default), then files=(*.txt) will put the string `*.txt` in `files`'s first element. So `[[ $files ]]` will test `[[ "*.txt" ]]`. It's also not very good style to use the side effect of treating an array as a string to expand the first element, it's a good idea to be explicit that you expect `files` to be an array and didn't just write a typo. It's easy to think that the author that wrote `cp "$files" "$dir/"` intended to copy all the files, not just the first.
[[Lhunath]]
The above test only works if `shopt -s nullglob` is set. If it is not set (it's not set by default), then files=(*.txt) will put the string `*.txt` in `files`'s first element. So `[[ $files ]]` will test `[[ "*.txt" ]]`. It's also not very good style to use the side effect of treating an array as a string to expand the first element, it's a good idea to be explicit that you expect `files` to be an array and didn't just write a typo. It's easy to think that the author that wrote `cp "$files" "$dir/"` intended to copy all the files, not just the first. [[Lhunath]]
Line 34: Line 27:
 I should have been more explicit that I was suggesting a change to the first code block on that page, i.e., after `shopt -s nullglob dotglob`. I'd already carried out experiments where there were no matches for the glob pattern so a literal asterisk was being tested for (which always returns as true). Anyhow, I agree with your point about style: it's better for code readability to be clear about what exactly is being tested. Thanks for the response - [[AnthonyGeoghegan]]  . I should have been more explicit that I was suggesting a change to the first code block on that page, i.e., after `shopt -s nullglob dotglob`. I'd already carried out experiments where there were no matches for the glob pattern so a literal asterisk was being tested for (which always returns as true). Anyhow, I agree with your point about style: it's better for code readability to be clear about what exactly is being tested. Thanks for the response - AnthonyGeoghegan

'''Clarification on Arrays'''

On
[[http://mywiki.wooledge.org/BashGuide/Arrays#preview]] there is an example that states

''Quote''

This is the right way to do it:

{{{
$ files=(*) # Good!
}}}
This statement gives us an array where each filename is a separate element. Perfect!

''Unquote''

I do not understand this and suspect that something might have been left out within the parentheses. Would one of the maintainers care to explain or comment on this please?

Thanks.

This page is for any feedback on the BashGuide. Feel free to ask any questions you want.

Q: I would like to cover bash in a course I will soon be teaching. May I use these materials for my course, provided the source is cited? Thanks for this excellent work, btw.

Absolutely. Perhaps we should consider putting a license on these documents. Creative commons something perhaps. - Lhunath

Q. The following suggestion can be harmful: echo 'PATH="$HOME/bin:$PATH"' >> "$HOME/.bashrc" If someone places a script named 'ls' in the bin directory of $HOME, you would be running it every time you typed 'ls', instead of running the builtin 'ls'. This can be harmful. I suggest echo 'PATH="$PATH:$HOME/bin"' >> "$HOME/.bashrc"

It is not harmful. Anyone with write access to ~/bin will generally have write access to ~/.bashrc, so there is no additional loss of security here. The original proposal also allows the user to wrap standard utilities, which yours cannot (in fact, that exactly why you proposed it). I believe being able to wrap utilities can be very useful. - Lhunath

Feedback: I could not understand the HereDocument page (found another source that helped) and I think the page could do with working examples and a more thorough explantion. Rest of course is wonderful though, I learn so much today, thanks :)

Suggestion

First off, many thanks for providing the best online resource for learning Bash scripting. Secondly, I hope this page is the appropriate place to make this comment.

In a script, I want to check if there are files in a directory that matched a certain glob pattern. Question 4, check whether a directory is empty or not provided the information that I was looking for. I haven't previously used arrays in Bash but it occurred to me that instead of (( ${#files[*]} )), the following test might be easier (simpler syntax to remember) for beginners to use:

[[ ${files} ]]

From man bash, Referencing an array variable without a subscript is equivalent to referencing the array with a subscript of 0. If the first array element is empty (or unset?), that should imply that the array itself is empty and that the glob pattern failed to match any files. I've done a few tests locally and it seems to work fine for me - though there may be some edge cases that I haven't considered. - AnthonyGeoghegan

Anthony,

The above test only works if shopt -s nullglob is set. If it is not set (it's not set by default), then files=(*.txt) will put the string *.txt in files's first element. So [[ $files ]] will test [[ "*.txt" ]]. It's also not very good style to use the side effect of treating an array as a string to expand the first element, it's a good idea to be explicit that you expect files to be an array and didn't just write a typo. It's easy to think that the author that wrote cp "$files" "$dir/" intended to copy all the files, not just the first. Lhunath

  • I should have been more explicit that I was suggesting a change to the first code block on that page, i.e., after shopt -s nullglob dotglob. I'd already carried out experiments where there were no matches for the glob pattern so a literal asterisk was being tested for (which always returns as true). Anyhow, I agree with your point about style: it's better for code readability to be clear about what exactly is being tested. Thanks for the response - AnthonyGeoghegan

Clarification on Arrays

On http://mywiki.wooledge.org/BashGuide/Arrays#preview there is an example that states

Quote

This is the right way to do it:

$ files=(*)      # Good!

This statement gives us an array where each filename is a separate element. Perfect!

Unquote

I do not understand this and suspect that something might have been left out within the parentheses. Would one of the maintainers care to explain or comment on this please?

Thanks.

BashGuideFeedback (last edited 2013-12-18 02:56:25 by Chandra)