I am thinking about installing the player for http://wolfframalpha.com/ but they have a .sh that is pushing a Mbyte in size. While reading through the start of the script i came across a section using dd. this bothered me so Id like some help reading exactly what this bit of code is going to attempt to perform on my laptop:

Id post the entire script, but its a bit large as stated above.

You mean http://www.wolframalpha.com/


What exactly have you downloaded? I put 'Wolfram Alpha Player' in to Google and the first hit takes me to something which is 577MB

The function you post is using three arguments, so it should be useful to know what's being passed to it. Is this .sh all plain text? I've seen installers for stuff provided as .sh files but only small part at the start is plain text, the rest is binary stuff.

from what little ive looked at it is all plane text.

its called CDFPlayer_9.0.1_LINUX.sh

Its a player from their web site to interact specifically with:

http://demonstrations.wolfram.com/AmdahlsLaw/

something to play with for my Computer Organization class. Just reading through and found the dd commands. i typically dont like dd commands being run if i dont know what they are writing over on my system.

I think you should share the code on a pastebin: http://fpaste.org/

Or provide a link to the shell script in question.

ill try again, but dangz gedit is failing to open the file and the yank to clipboard commands for VI are not working as they are not overwritting what i have in there now:

gg"+yG

does not seem to work.

You can always use curl to send the file to sprunge:

It will spit out a URL you can share.

For example, here is how I sent my motd, that you can see here: http://sprunge.us/CWTY

1 members found this post helpful.

nice, but sadly that site does not seem to like me:

thought it might work if i first catted it into a .txt file, nope same reset by peer error.

ok, not going to happen. sorry if you need more of the code, please follow the link for the app from wolffram and download the .sh from there. after waiting well over an hour and having my laptop lock up due to gedit sucking up 100% of the CPU and RAM on a i5 with 8G ram i had to fight with the system to terminate gedit. file is just to large for the gui editor to access. if not, then ill just delete the .sh and not risk the install.

a 597M .sh file?

0 597M 0 5137k 0 0 866k 0 0:11:46 0:00:05 0:11:41 1006k

Yeah, that's a real winner.

It's a shell wrapper for installation. I've seen that before somewhere.

1 members found this post helpful.

Well I can't say exactly what the dd does, but if you notice there's no "of" argument, so it's not actually writing to anything. From what I can tell it's just dumping a file to stdout.

1 members found this post helpful.

Hi,
The dd man page implies that the dd commands running under "test" read from stdin and write to stdout. Given that the size of the shell script is 500+MB this is obviously a small shell script with a large binary attached to the end ( e.g cat <binary> >> <small shell script>). This is a standard trick for installing binaries ... e.g Virtualbox does this.

You can "see" the shell script by running "cat <big fat install package> | less". You will see the shell script part and as you scroll down, it will become obvious where the script ends and the binary begins. Typically the shell script allows you to specify options. The most useful is the "extract but do not install" option which will give you an opportunity to extract the binary and examine it (it may turn out to be a tar file) for "interesting" attributes!

As always YMMV

cheers
pete

pete hilton
saruman@ruvolo-hilton.org

1 members found this post helpful.

ahh many thanks all for the help and info.

Yes, without 'of=' it's basic function would be similar to reading a file with 'cat' or 'less'. So in itself it's not writing over anything dangerous. Since it's inside a function, my understanding is it'll dump the results out for the caller of the function - so if you want to know where exactly the output ends up, you'd have to look for parts of the code that call the 'MD_dd' function. The first 'dd' command reads the input, and passes it to STDOUT, which in turn is directed to second block of code that has two more 'dd' commands. Those two will chop it up and pass it along to STDOUT again (which I believe then spits it out to caller of the function).

The first parameter ($1) is the name of the file or device it reads from. The second ($2) defines the size of the 'block' that it reads every cycle. conv=sync means it pads every input block with nulls to make it the size given by second parameter. The third parameter ($3) basically defines the total number of bytes it reads from the given input handle ($1).

The function will then 'chop' whatever it reads, into 1 kilobyte chunks, and spits those out to the caller of the function. Any remaining bytes that don't fill a full 1 kilobyte chunk are given out as the last chunk (which then might be smaller than 1 kilobyte).

Any possible error messages are silently discarded (directed to null device).

n/m. I am tired.