Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Originally posted by Doctor Q
you can also invoke a shell script by naming the shell and the shell script file, e.g., sh myscript, in which case the shell script only needs read permission.

ah, i gotcha. yes, in that case the name of the file is an argument and the shell deals w/ it only in the sense it's passing the name to the sh program. when sh opens a pipe to read the file, it only needs the read bit set, as you indicated.

i thought you meant you were executing the file directly, e.g.:

% myscript
 
Originally posted by Doctor Q
In Terminal, you invoke commands by typing the command name, or a path and command name. When invoked that way, the command should have execute permission. But you can also invoke a shell script by naming the shell and the shell script file, e.g., sh myscript, in which case the shell script only needs read permission.

Programs and scripts can also be executed by the operating system or by other applications. Examples: The at, batch, and cron commands execute commands in the background (i.e., without showing their output on the screen) on a sheduled basis. A web server (e.g., Apache) will execute commands in its cgi-bin directory when the appropriate URLs are specified by a web browser connecting to that server. And lots of applications have plug-ins, filters, and other extras that are executable code. So there are lots of ways that programs get invoked!

True, but we're not talking about invoking a command here. Instead the discussion has centered around simple execution and how an OS determines that a file is executable. In your examples, the scripts are not then executed directly. Instead, the shell itself is executed and directed to read the contents of the script and invoke the commands contained therein. It's a method of invoking the script, true, but the script isn't itself executed.

If you want to get into the nuts and bolts of a script, the script itself is never properly executed. Instead, the interpreter (either the default or the one specified after the shebang) is executed and the remainder of the script is used as the input.

In the case of batched jobs (batch, at, cron, etc.) commands that are run do need to be set as executable.
 
Originally posted by paulwhannel
Very rarely are those .exe attachments worth viewing anyway tho ;) Once you've seen elf bowling once, you've seen it a thousand times...

pnw [/B]


99% of the .exe attachments I receive from others are - you guessed it - viruses.

Or .pif files or .bat files. I just look at them and laugh - knowing that somewhere out there a PC is being compromised from this very e-mail.
 
Originally posted by BrandonRP0123
99% of the .exe attachments I receive from others are - you guessed it - viruses.

Or .pif files or .bat files. I just look at them and laugh - knowing that somewhere out there a PC is being compromised from this very e-mail.

Last week I got an e-mail, cleverly disguised as a bounceback message -- it made it look like I tried to send a file to someone and it failed.

The attachment they made it look like I was trying to send was a .EXE file. Clever.

For some odd reason, none of my coworkers would let me try to run it on their windows boxen so I could see what it was. :(
 
You may not be able to (or want to) run a suspicious .exe file, but you might be able to peek at some of the messages it contains with the strings command in Terminal.

Example: You saved e-mail attachment im_not_a_virus_really_im_not.exe to your Documents folder. Type the command

strings -20 ~/Documents/im_not_a_virus_really_im_not.exe

to see all strings of at least 20 consecutive ASCII characters in the file. If one of the messages is "Ha ha, I erased your C: drive!" then you'll have a clue what the mysterious .exe file might be.
 
Originally posted by Doctor Q
You may not be able to (or want to) run a suspicious .exe file

My wanting to run it on a coworker's machine was meant tongue-in-cheek. Sort of a "Hey, I think I got a virus, but it won't work. Can I try it on your Windows box?" type of scenario.

As an aside, folks on the Windows side of the fence are often taught early on to not open up attachments from people they don't know ("Don't accept candy from a stranger".)

UNIX admins are suspicious by nature, so that advice goes without needing to be stated.

But what about from a Mac perspective? I haven't yet received a strange Mac binary in an e-mail or otherwise. I understand that its due mostly towards lower userbase, but does that phenomenon exist at all on the Mac?
 
Actually, I understood your tongue-in-cheekiness. But it seemed like a good opportunity to mention another tip. So go ahead and test your viruses on your co-worker's PC!

I have never met a Mac virus, in an attachment or otherwise. Other than the platform-independent Word-macro viruses, the last one I read about for Mac was a humorous one, not a harmful one, and it was under System 7!

I'm sure there are some out there, but I certainly don't worry about them.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.