Differences between revisions 23 and 26 (spanning 3 versions)
Revision 23 as of 2013-12-17 13:28:45
Size: 5023
Editor: 117
Comment:
Revision 26 as of 2024-10-03 13:28:48
Size: 5517
Editor: hastec
Comment:
Deletions are marked like this. Additions are marked like this.
Line 47: Line 47:
`find .[!.]* -prune -type d` # list dot directories find .[!.]* -prune -type d # list dot directories
Line 49: Line 49:
`find .[!.]* -prune -type f` # list dot regular files find .[!.]* -prune -type f # list dot regular files
Line 51: Line 51:
`find .[!.]* -prune -type l` # list dot symbolic links find .[!.]* -prune -type l # list dot symbolic links
Line 53: Line 53:
`find [!.]* -prune -type d` # list non-dot directories find [!.]* -prune -type d # list non-dot directories
Line 55: Line 55:
`find [!.]* -prune -type f` # list non-dot regular files find [!.]* -prune -type f # list non-dot regular files
Line 57: Line 57:
`find [!.]* -prune -type l` # list non-dot symbolic links find [!.]* -prune -type l # list non-dot symbolic links
Line 62: Line 62:
Thanks. [[Chandra]] Thanks. --[[Chandra]]


'''Q:''' Hello, first of all, I would like to thank you so much !!
  . Your work is amazing and help me so many times.
  . I'm a backend developer and even if I don't have your level, I wish I could help too with a project just created on github: https://github.com/hastec-fr/apash
  . If you have time to take a look, I would be very interesting by your feedbacks to enhance it (because it's difficult to find people around me interested by the subject).

Again, thanks for all. --[[hastec]]

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

Has this page been hacked?

http://mywiki.wooledge.org/Arguments

If so, could you kindly restore it? Thank you. -- Chandra

  • Some spammer had replaced it, yes. It has been reverted back to the previous version now. -- geirha

Q: In the Topic Brace Expansion the example echo {/home/*,/root}/.*profile" does not work for me(/home/* does not get expanded), bash Version 4.2.37. can u help?

  • Then either /home does not exist, or it exists but contains no files. If you're on OSX, the home directories are in /Users instead of /home.

Question about find

I refer to the guide at http://mywiki.wooledge.org/UsingFind and want to ask a question about the prune action in find.

The following commands work for me in the current directory without doing recursive descent, which is exactly what I want:

find .[!.]* -prune -type d # list dot directories

find .[!.]* -prune -type f # list dot regular files

find .[!.]* -prune -type l # list dot symbolic links

find [!.]* -prune -type d # list non-dot directories

find [!.]* -prune -type f # list non-dot regular files

find [!.]* -prune -type l # list non-dot symbolic links

Can you please add a section on the above page on find explaining why this works because it is a lot simpler than explained in the find documentation. If on the contrary, this usage is inadvisable, an explanation of why and the proper way to go about this will be helpful.

Thanks. --Chandra

Q: Hello, first of all, I would like to thank you so much !!

  • Your work is amazing and help me so many times.
  • I'm a backend developer and even if I don't have your level, I wish I could help too with a project just created on github: https://github.com/hastec-fr/apash

  • If you have time to take a look, I would be very interesting by your feedbacks to enhance it (because it's difficult to find people around me interested by the subject).

Again, thanks for all. --hastec

BashGuideFeedback (last edited 2024-10-03 13:28:48 by hastec)