Nowadays, even trying to read a page of "hyper-text" requires doing battle with several levels of malicious software.
When something better comes along I'll switch away from using the UNIX shell.
But I am not sure I'll live long enough to see that day.
Meanwhile I am too busy using the shell to engage in that battle with hypertext. It could just be my perception, but after years of practice, I think I am winning.
Useful things in bash:
export IFS=$'\n'
export IFS=$'\n'
for I in `$COMMAND` do
$OTHER_COMMAND "${I}"
done
find ./ -print0 | xargs -0 $COMMANDBe careful exporting a changed IFS. That will inherit into child commands, which can cause unexpected breakage. A better model is to simply set IFS in the bash script (without export) or even better, as a one-off prefix to a command
# leaves IFS set for following commands
IFS=$'\n'
$COMMAND
# only sets IFS for one command
IFS=$'\n' $COMMAND
oldIFS="$IFS"
IFS=$'\n'
# ...stuff...
IFS="$oldIFS"
cmd_with_nonstandard_ifs() {
local IFS='\n'
$COMMAND
}
cmd_with_nonstandard_ifs
# IFS is back to normal here
# backticks need to be escaped when nested
FOO="`basename "\`command_that_outputs_a_path\`"`"
# much easier to read in the modern form
FOO="$(basename "$(command_that_outputs_a_path)")"
$ ls -1
a bc
a b c d e
ddd eee
$ for file in * ; do echo "[$file]" ; done
[a bc]
[a b c d e]
[ddd eee]
show_args() {
for arg in "$@" ; do
echo "arg that supports spaces: [$arg]"
done
}
show_args "foo bar"
Of course, this is always a nice option that bypasses the need for bash.
Minor suggestion: "find ." and "find ./" are identical.
> ...and arguments be expanded correctly with "$@"
That assumes that your bash is contained within a script, yes? It doesn't work for commands entered directly in a shell?
> ...unless you're using a really ancient version of bash, you shouldn't use backticks for command substitution.
I was -stupidly- unaware that backticks would nest. I always use $() when I want to nest command substitutions.
> "find ." and "find ./" are identical.
Oh, I know. I have the largely unjustifiable habit of always putting a path in a find invocation, as well as always spelling "the current directory" as ./
> > find | xargs
> Of course, this is always a nice option that bypasses the need for bash.
Don't forget -print0 and -0 if you expect to have to handle arguments that contain spaces! ;)
Or a function. (that is, anywhere the $1, $2, ... variables are available, as "$@" (must have the double-quotes!) just copies $1, $2, .. without changing the word splitting.
> as well as always spelling "the current directory" as ./
That's actually a very good habit to be in a lot of other commands. It's unnecessary with find, but it's harmless either way.
Imagine, if you can, a world in which programs are things designed to help their authors/users, not adversaries to be exploited or defeated.
We can imagine that world, but does it really help professionals in any way if they do imagine it?
In that time, only a few people had access to computing and network resources, but they were all well-educated, reasonably well-paid and curious, with lots of motivation to help each other out and little motivation to undermine each other. It might have remained just a brief blip of history, except that so many technologies developed during that time, designed with the security assumptions of that time (i.e. practically none), became the fundamental underpinnings of our modern world, like MS-DOS and Unix.
It's amazing how fast you can go from "that guy with the curious hobby" to "some guy that naturally also owns and uses a computer, as everyone else does".
("Anyone can learn S-expressions.")
$ ls -l
((foo 2015-06-09 6 bar baz (rw rw r))
(file2 2012-03-04 18789 bar baz (rwx rwx rwx)))
Isn't that what PowerShell is?