Shell scripts are evilFollow

c:\shell - Found at ocean!

:ashell













get offa ma lawn!

Currently I hate solaris. I'm testing to see if the system is little endian or big endian by compiling a simple c program and then running it and nomnoming the output. And then using that output to write stuff to a header file for my actual program.

The code I'm using to capture is "out=$(./a.out)" and it works perfectly on CentOS 5.6 Linux (i386), Ubuntu 10.04.2 Linux Server (x86_64), and even Mac OS X (PPC)! But on Sun Solaris 8 (SPARC) is I get the most annoying error. "test-endian.sh: syntax error at line 21: 'out=$' unexpected"

That $ should be there. (Removing it doesn't fix the problem on solaris anyway. And causes false positives on the other systems as well.)

edit: After many trials and errors, removing the $ and putting `(./a.out)` worked for all systems. Solaris is stupid.

Edited, Nov 27th 2011 5:42am by Deadgye

To be fair, I believe that is the more common way to spawn a subshell or run a shell command.

Probably could've saved some time with

./a.out > file.txt
out=`cat file.txt`

Try and make a game out of it! A shell game!

In one post I've learned more then I have in a whole semester "learning" ubuntu.

Yes, people who know very little about the technology they're working with often find said technology difficult or evil. I grew up in a windows world and only started working with linux 8 years ago. Having been handcuffed to the handicap that is the DOS/Windows command environment and "batch" files before, shell scripting to me is the most awesome thing since sliced bread. There's a reason why thousands of sysadmins will make sure that cygwin is one of the first packages installed on a new windows server.

My prof's answer for this is "oh it's not working? try changing all your ` to ".

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.



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:

 
ldd /bin/sh 
        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) 
        /lib64/ld-linux-x86-64.so.2 (0x00000033f6800000) 

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.



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

Neither of the commands require root access. The first is just a list showing that /bin/sh is actually just a symbolic link to /bin/bash. Which is why syntax which appears to work in sh on linux will not work on solaris. The linux script is actually running bash.

The security element to this is that even though *you* may not be running as root, the root user uses that shell to run all the startup stuff. You really want to use a more stable and less subject to change shell for that. The linux devs did that linking out of sheer laziness. A lot of the devs just wrote their init script in bash. When time came to consolidate a bunch of different pieces into full distributions, rather than spend the time correctly re-writing the script to use a strict sh syntax, they went the easy route and just linked sh to bash. That way any init script written in either shell would work on any linux system. It's a great example of the exact wrong way to fix a problem.

Oh. The second command lists the dynamically loaded libraries used by a binary. Since it looks like you're doing some compiling you might find it useful. It allows you to work backwards with a binary and learn what libraries it's dependent on. Incredibly useful command for debugging odd problems with code portability btw. The security angle there is that when you dynamically link a library, the binary will behave differently depending on the libraries themselves. Normally that's necessary for portability. It means you don't have to recompile your binaries for every os/kernel/whatever it runs on. The problem is that if someone replaces a library with something malicious, bad things can happen. Usually, if the libraries are all pointing explicitly to local libraries (like /usr, /usr/local, etc), you're ok. But I've seen some pretty "interesting" library paths. It's something to think about when compiling code. Be aware of what paths you're using for libraries if you explicitly link them into your code.