I missed the classes where he was going over shells scripts so I was using his examples of scripts to try and piece together my own knowledge. I didn't even know you could specify bash inside a shell script like that.
Yup. Personally, I prefer ksh because like sh, it's stable but has additional features, but unlike bash and tcsh it's not also a user command line shell. Shells used for command line work tend to change and add/remove features over time, which can make shell scripts break.
All my scripts started with #!/bin/sh, but solaris was still the only system to have a problem with me attempting to use out=$(./a.out).
That's not a problem with Solaris. It's a problem with linux (and one of the many things I berate the linux development community about). Try this on your computer:
ls -l /bin/sh
lrwxrwxrwx 1 root root 4 Feb 22 2011 /bin/sh -> bash*
You're not actually running sh. You're running bash. Something which apparently the idiots who develop linux thought they'd do because "bash is better". It's stupid because bash *isn't* better if you're actually doing single user scripting/repair. There are a couple reasons for this. First is the issue with potential inconsistencies over time with a user shell like bash. Hasn't happened yet (that I know of), but I saw this first hand with tcsh about 10 years ago so it's really just a matter of time. Difference being that *nobody* used tcsh for system level scripts (like the stuff in /etc/init.d/). Um, and also someone who thinks they're writing a sh script and thinks that certain commands will work, and is then surprised when this supposedly portable shell script they wrote doesn't work on another system (like what happened to you). Don't get me started on vi linked to vim either btw.
The second reason is that ideally (and to be fair Solaris doesn't still do this) you want the default shell used by your startup scripts (and single user mode) to be a separate and statically linked binary from the one(s) used during normal operation. This is so that just in case say your /usr directory structure (which could even be on a separate disk partition) should not be available on boot, you can still boot into single user mode and fix things. It's a rare problem to run into these days, so it's not a huge huge deal, but it's still a bad thing.
Then there's this:
linux-vdso.so.1 => (0x00007fff31dfc000)
libtermcap.so.2 => /lib64/libtermcap.so.2 (0x00000033fa800000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000033f7400000)
libc.so.6 => /lib64/libc.so.6 (0x00000033f7000000)
See that first line? Can anyone in the class tell me why this is a potential security problem? Remember, that this is the shell that's run as root on startup and will initialize your network, your firewall rules, your login environment, and every other thing you computer does, or that any user does with the computer.
Linux does many things right, but they managed to **** up a few things as well.
I probably would have used outputting to a file and reading from the file if I realized how much easier it was to do with scripts. Outputting to files in pure c is something I didn't want to do for what was supposed to be a simple test. :p Google also wasn't giving me the best of search results so I attempted to use what I found.
Honestly, it's usually easier to just pipe the output directly into whatever you want to do with it. Only dump the output to a file if you have to. Sometimes, it's the easiest way to deal with some bulky data. Doubly so if you're going to read it multiple times. A common scripting mistake is to run the same command several times parsing for different bits of output each time. If you're doing that, dump it to a file and read the file (don't forget to delete the file later though. Cleanliness is next to something important I'm sure!). But if you're just running a command and testing the output to check for something (like in your case), I'd just pipe the output directly to a sed/awk expression designed to find the bit I need and then test it. Edited, Nov 29th 2011 11:48am by gbaji