[jay3ld]

Uh. On a pc thers .bat files that will run commands though the computer. is there such a file for the mac that will run commands like the pc does

Heres an example of a .bat file

Breakthrough.bat

@echo off
echo Pure MOHAA UK Restart Script
:TOP
echo Starting Server
start /wait moh_breakthrough_server.exe +set dedicated 1 +set fs_game maintt +set sv_maxclients 50 +set net port 12203 +set net_ip 212.42.16.88 +set sv_hostname "www.RSoBB.co.uk | Realism | Join Today!" +set g_gametype 6 +exec server.cfg +map dm/mohdm6
echo Restarting Server!
goto TOP

Thats an example of a pc .bat file for a game. now how is this done for a mac?

[Diggory Laycock]

either AppleScript or Unix Shell Scripting.

http://www.google.com/search?q=apple...8&oe=UTF-8

http://www.google.com/search?hl=en&q...ng&spell=1

[edit] - Royal Society of Bum Bandits <snicker>.

[larkost]

Or Perl, Python, Ruby, etc...

[jamil5454]

UNIX shell scripting is very easy, and Perl, Python, and Ruby are simple programming languages that offer built-in scripting. If I were you I would use the BASH shell for scripting. Here's a simple BASH script that should open a new shell:


#!/bin/bash
/bin/tcsh


PS - this works on linux but not sure about OS X since I don't have my iBook just yet...

[Millennium]

Off the top of my head, I know of the following scripting languages which come with OSX by default:

AppleScript
bash
tcsh
zsh
tcl (but not Tk)
perl
python
ruby

Of these, bash is probably the most similar to the batch files you're used to, since bash is the default Unix shell. The commands are still almost all different from what you're used to with DOS, but the idea -take shell commands and wrap them up into one package- is pretty much the same. If you're looking for something more powerful, I suggest starting with tcl, though you'll eventually want to move to something even more powerful than that. I've recently taken a liking to python, but perl and ruby are both very good, and have their fans.

AppleScript is sort of the odd one out. Its own command-line facilities are not very good, though it can be made to run scripts from other languages, and this helps a lot (embedding Perl one-liners into AppleScript is something of a work of art). However, its ability to script existing GUI apps is second to none.

[Xeo]

Originally posted by jamil5454:
UNIX shell scripting is very easy, and Perl, Python, and Ruby are simple programming languages that offer built-in scripting. If I were you I would use the BASH shell for scripting. Here's a simple BASH script that should open a new shell:


#!/bin/bash
/bin/tcsh


PS - this works on linux but not sure about OS X since I don't have my iBook just yet...

That would work, but it's odd (to me, at least).

Oh, and Mill, you can add sh to your list as well. You listed several other shells so it seems to have simply been forgotten, and as my shell scripting shell of choice, that makes me .

[Brass]

Originally posted by Millennium:
bash is the default Unix shell.

I believe that if there is any 1 default unix shell, it would be the Bourne shell ("sh"). However, this is very similar for shell programing to the Bourne Again shell (bash).

[jamil5454]

He probably meant Linux, not UNIX.

Go install your favorite Linux distro and report back to me what the default shell is.

But yes, the Bourne shell was the first UNIX shell and is probably the most famous.

[TimmyDee51]

Here's another great thing about shell scripting on Mac OS X -- you can roll them into AppleScript Studio apps. That feature was absolutely huge for my job last year. I was able to write an app that intercepted the login process before the Finder and Dock appeared and asked for our network specific authentication. Once they were properly authenticated, it mounted four shares and launched the Finder and the Dock. All of the backend stuff was done using shell scripting. I can't wait for an excuse to use it again.

[Millennium]

Originally posted by jamil5454:
He probably meant Linux, not UNIX.

Actually, I meant "Unix shell" as "the shell used for OSX's Unix layer". As of Panther, bash is the default; before then it was tcsh.

The closest thing to a default across different flavors of Unix is, as others have mentioned, probably the Bourne shell, often simply called sh. Most Linux distributions don't include this at all, and neither does OSX; instead they use a compatible but more powerful replacement, typically bash or ksh (which doesn't come with OSX but can be installed later).

[Xeo]

Originally posted by Millennium:
Actually, I meant "Unix shell" as "the shell used for OSX's Unix layer". As of Panther, bash is the default; before then it was tcsh.

The closest thing to a default across different flavors of Unix is, as others have mentioned, probably the Bourne shell, often simply called sh. Most Linux distributions don't include this at all, and neither does OSX; instead they use a compatible but more powerful replacement, typically bash or ksh (which doesn't come with OSX but can be installed later).

So in one of my last posts, I mentioned that you should have included sh in your list of shells. This post then confused me because you say sh is not in OS X. I went into Terminal, typed sh and sure enough, a shell started. However, I typed man sh, and got the man page for bash. So I went into /bin and typed md5 sh and md5 bash and the hashes were identical. So sh is really just bash in OS X.

But I have a question. Why is the prompt different when I type sh vs. bash. If the binary files are identical, shouldn't the resulting prompt be identical as well? Shouldn't they get their info for how to set the prompt from the same source?

[Millennium]

Originally posted by Xeo:
But I have a question. Why is the prompt different when I type sh vs. bash. If the binary files are identical, shouldn't the resulting prompt be identical as well? Shouldn't they get their info for how to set the prompt from the same source?

I'm guessing that this is a bash thing. If you start it up via the sh link, it reconfigures itself to use the default prompt from sh, which is different from the default prompt it normally uses. This is a compatibility issue; they want to make sure that older sh scripts run properly, while still being able to do their own thing.

[Millennium]

Originally posted by Xeo:
So in one of my last posts, I mentioned that you should have included sh in your list of shells. This post then confused me because you say sh is not in OS X. I went into Terminal, typed sh and sure enough, a shell started. However, I typed man sh, and got the man page for bash. So I went into /bin and typed md5 sh and md5 bash and the hashes were identical. So sh is really just bash in OS X

IIRC, if you do a ls -l in /bin, you'll find that sh is just a softlink to bash.

[Xeo]

Originally posted by Millennium:
IIRC, if you do a ls -l in /bin, you'll find that sh is just a softlink to bash.

No, it's a separate file. Could be a hard link, but I don't know how to tell.

[Brass]

Originally posted by Xeo:
No, it's a separate file. Could be a hard link, but I don't know how to tell.

"ls -l /bin" shows that there is only 1 (hard) link each for bash and for sh. And also that neither is a symbolic link. So they are both distinct files (albeit of exactly the same size, and as someone else said earlier, even the same content).

"sh" is (arguably) the default shell on unix systems and many script utilities use it, simply because it's the ONLY shell that they can be sure will be present on the largest number of systems. If you want to write a shell script that is as portable as possible, it will always start with the line "#!/bin/sh" to run on "sh" (the bourne shell - or whatever bourne-shell compatible shell "sh" really is for that system).

I suspect that this is the only reason that Apple have created a second copy of "bash" and called it "sh", as "bash" was specifically created to be fully script compatible with "sh", but with additional enhancements (eg, history, autocomplete).

[Xeo]

Originally posted by Brass:
"ls -l /bin" shows that there is only 1 (hard) link each for bash and for sh.

Do you find that information in the second column of "ls -l"? Or where?

[siMac]

Heh heh, talking about Unix really brings out the mods!

[utidjian]

Originally posted by Xeo:
Do you find that information in the second column of "ls -l"? Or where?

If you do something like:

Code:
core:~ physicsadmin$ ls -l /bin/*sh
-rwxr-xr-x  1 root  wheel  603488 27 May 11:23 /bin/bash
-r-xr-xr-x  1 root  wheel  348068 27 May 11:23 /bin/csh
-r-xr-xr-x  1 root  wheel  603488 27 May 11:23 /bin/sh
-r-xr-xr-x  1 root  wheel  348068 27 May 11:23 /bin/tcsh
-rwxr-xr-x  1 root  wheel  479120 27 May 11:23 /bin/zsh

Shows that csh and tcsh are the same size and sh and bash are the same size. However... if you do:

Code:
core:~ physicsadmin$ ls -li /bin/*sh
677842 -rwxr-xr-x  1 root  wheel  603488 27 May 11:23 /bin/bash
677844 -r-xr-xr-x  1 root  wheel  348068 27 May 11:23 /bin/csh
677853 -r-xr-xr-x  1 root  wheel  603488 27 May 11:23 /bin/sh
677864 -r-xr-xr-x  1 root  wheel  348068 27 May 11:23 /bin/tcsh
677851 -rwxr-xr-x  1 root  wheel  479120 27 May 11:23 /bin/zsh

You can see that the serial number (or inode number) on the left is different for each file. This means they are all separate individual distinct files. If, say, /bin/sh and /bin/bash had the same serial number then they are the same file... IOW "hard linked" to the same serial number or inode number.

Yet... if you do:

Code:
core:~ physicsadmin$ md5sum /bin/*sh
50abf0f454724ee50c140c1cdc14241e  /bin/bash
1f82aa46e357e8449b08e52c65719e1c  /bin/csh
50abf0f454724ee50c140c1cdc14241e  /bin/sh
1f82aa46e357e8449b08e52c65719e1c  /bin/tcsh
298b970bd265adc0103cfe8db93dc908  /bin/zsh

You can see that /bin/bash and /bin/sh are bitwise identical as are /bin/tcsh and /bin/csh. IOW they are identical copies.

Another check... if you do:

Code:
core:~ physicsadmin$ /bin/bash --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin7.0)
Copyright (C) 2002 Free Software Foundation, Inc.
core:~ physicsadmin$ /bin/sh --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin7.0)
Copyright (C) 2002 Free Software Foundation, Inc.
core:~ physicsadmin$ /bin/csh --version
tcsh 6.12.00 (Astron) 2002-07-23 (powerpc-apple-darwin) options 8b,nls,dl,al,kan,sm,rh,color,dspm,filec
core:~ physicsadmin$ /bin/tcsh --version
tcsh 6.12.00 (Astron) 2002-07-23 (powerpc-apple-darwin) options 8b,nls,dl,al,kan,sm,rh,color,dspm,filec
core:~ physicsadmin$ /bin/zsh --version
zsh 4.1.1 (powerpc-apple-darwin7.0)

You can see that, indeed, /bin/bash and /bin/sh are the same thing... though it would not be correct to say "one and the same thing". Same for /bin/tcsh and /bin/csh. (/bin/zsh included for thoroughness and contrast).

For more contrast (or lack thereof) on many Linux systems, if you do:

Code:
[utidjian@cobalt utidjian]$ ls -l /bin/*sh
-rwxr-xr-x  1 root root  98388 Feb 16  2004 /bin/ash
-rwxr-xr-x  1 root root 593304 Mar 11  2004 /bin/bash
lrwxrwxrwx  1 root root      3 Jun 30 21:15 /bin/bsh -> ash
lrwxrwxrwx  1 root root      4 Jun 30 21:18 /bin/csh -> tcsh
lrwxrwxrwx  1 root root      4 Jun 30 21:15 /bin/sh -> bash
-rwxr-xr-x  1 root root 319520 Feb 17  2004 /bin/tcsh

You will see that /bin/sh is a "soft link" to /bin/bash and /bin/csh is a "soft link" to /bin/tcsh.

As others have pointed out there are good reasons to still include /bin/sh and /bin/csh in modern systems.... even though they are mere copies or symlinks ("soft links") of /bin/bash and /bin/tcsh, respectively. One of the main reasons is... when one invokes /bin/sh in a shell script it will behave in a very predictable and clearly defined way. According to the manpage bash, when invoked with /bin/sh,
"tries to mimic the startup behavior of historical versions of sh as closely as possible, while conforming to the POSIX standard as well."

[Brass]

Originally posted by Xeo:
Do you find that information in the second column of "ls -l"? Or where?

As the previous poster indicated, you can use the "i" flag to "ls" to get the inode number, but a regular "ls -l" also shows the number of (hard) links to a file in the second column, as you suggested. Either method will determine if they are links to the same file (provided you get a 1 for the number of links), but the inode method is of course more reliable, if you find that there are more than 1 link.

Check "man ls" for the details.

[jamil5454]

Does the "file" command work under OS X? Example:


root@localhost# file /bin/sh


should give you the file information for /bin/sh




I'm using slackware 10 but I'm getting my iBook tomorrow; I RAWK!

[Brass]

Originally posted by jamil5454:
Does the "file" command work under OS X? Example:


root@localhost# file /bin/sh


should give you the file information for /bin/sh




I'm using slackware 10 but I'm getting my iBook tomorrow; I RAWK!

Yes:

% file /bin/sh
/bin/sh: Mach-O executable ppc
%