DirectNET

Data Center Management Solutions including UPS Systems, Data Center Cooling, KVM over IP & IP Power Strips, Server Racks and Server Rack accessories; KVM Switches and KVM Extenders; Rackmount Monitors and Rackmount Keyboards.

NAVIGATION
	Home
	Store

INSIDE MAC
	Television Shows
	Broadcast Shows
	Daily News Shows
	Special Shows

EVENTS




DAILY TIPS
	Design
	Mac OS X
	Mac OS X UNIX

COMMUNITY
	Forums
	Surveys

NEWS
	Current
	Press
	Archive

FEATURES
	Editorial
	Dr. Mac
	Reviews
	Reader Reports

RESOURCES
	FAQ
	Documentation
	Learning Center
	MAN pages
	Glossary
	Tutorials
	Tips
	Links

OUR PARTNERS

FAQ

Shells

	How do I "get to" Unix?
	How do change my shell?
	Why is /bin/bash listed in /etc/shells, but not installed?
	What's with all these NeXT directory names?
	How can I safely copy "Classic" apps and files from the command line?
	Can I launch apps from the shell?
	Why is the filesystem completely case-insensitive?
	Which shell should I use? Which is best?
	Can I view or set file creator and type codes from the command-line?
	Where should I add new shell commands and files?
	How do I change my PATH?

How do I "get to" Unix?

From the Finder, click Apps (/Applications), Utilities, Terminal.

How do I change my shell?

See User Administration.

Why is /bin/bash listed in /etc/shells, but not installed?

It was in /etc/shells because it ships with Darwin. I've heard it was removed from OSX because bash is GNU license which isn't compatible with the BSD license.
Contributed by Tracy Snell
(Unfortunately, it no longer comes with Darwin (as of 1.2). --MZ)

In any case, you should be able to grab it from here.

What's with all these NeXT directory names?

I don't want to break any internals until I understand them better, but one of the first things I did was create some "compatibility" (or "sanity") symlinks:

	user% su
	root# ln -s /Users /home
	root# ln -s /home /usr/home
	root# mkdir /usr/local/www
	root# ln -s /Library/WebServer/CGI-Executables /usr/local/www/cgi-bin
	root# ln -s /private/etc/httpd /usr/local/www/etc
	root# ln -s /Library/WebServer/Documents /usr/local/www/htdocs
	root# ln -s /private/var/log/httpd /usr/local/www/logs
	root# ln -s /usr/local/www /www

(tweak to fit your habits and preferences)

How can I safely copy "Classic" apps and files from the command line?

Short answer:

	G4 [/Developer/Tools] mzieg $ ./CpMac
	usage: CpMac [-r] [-mac] <source-path>... <dest-path>

Long answer:

According to MacOSX System Overview you can use CpMac to copy files HFS from the console while preserving their resource fork:
	Note: You can use the BSD cp or mv commands on a application package (or any
	other bundle) without ill effect. However, if you use those commands on a
	single-file CFM application, the copied (or moved) application is rendered
	useless. For the latter purpose, Apple includes the CpMac command-line utility.
It will react appropriately by splitting the file into two fork files when copying to a non-HFS filesystem and back.
The data fork file has same name as the file being copied and the resource fork file has the same name, prefixed with dot-underscore (._filename)
Contibuted by Benjamin Mironer

Can I launch apps from the shell?

Sure:

You can run aqua apps from the terminal. Say you want to run Preferences.app. Go to the Applications folder, where Preferences.app resides. This is a folder. Somewhere inside that folder is an executable that can be run in the terminal while you are in the Applications folder. This will bring up an aqua window. For instance:
/Applications/TextEdit.app/Contents/MacOS/TextEdit
On nextstep there used to be a way through a command line option that (like X windows) allowed for the display of an app from a remote machine on a local one. I don't remember what it was, but if you manage to dig up that information....
Contributed by Sunil Mishra

this also works...

use "open" (/usr/bin/open) and the folder. For example:

open /Applications/Key\ Caps.app/
will run the Key Caps application and automatically background it. Note that a quick "strings" on the executable seems to show a flag is possible:
-NSHost
and that just might throw the display to another host? I only have one machine so can't test.
Contributed by Wayne Folta
(note that the man page says "-NXHost opens the file on the specified host (if its window server is public)." However, Wayne has presented good evidence that the man page may have it wrong...testing will bear this out one way or the other :-)

David Cramer points out that the open(1) command works on directories as well, ie 'open /Users' or 'open .'.

Why is the filesystem completely case-insensitive?

Apparently that's just the way that HFS+ formatted partitions work, whether you're in MacOS or "Unix". Sounds like formatting a second drive in UFS might restore the "lost" expected Unix-like behavior...I'll try that Monday.

Which shell should I use? Which one is "best"?

They're all somewhat different, and they all have their own advantages and disadvantages. IMHO, tcsh isn't the friendliest shell in the world, so I think it's unfortunate that Apple choose it for the default. Most people find bash, zsh, or ksh (korn) to be the easiest to use. Of those, zsh is the only one actually included in the default installation, so you might want to find out a little more about it.

Here's some information about each of them:

General Information

Can I view or set file creator and type codes from the command-line?

I wrote a little Perl script to "wrap" the GetFileInfo command that comes on the Developer CD:

		bash$ whats /Volumes/MacHD/*              
		R*ch adrp       BBEdit Lite 4.6            
		CDrw dDrw       Glossary_schema.drw         
		MSIE adrp       Internet Explorer            
		MSWD adrp       Microsoft Word                
		NIFt adrp       NiftyTelnet 1.1 SSH r3          
		CARO PDF        ziegnet.pdf

You can also make changes using SetFile(1) (also on the Developer CD):

G4 [/Developer/Tools] mzieg $ ./SetFile
setfile [option...] file...
        -a attributes           # attributes (lowercase = 0, uppercase = 1)*
        -c creator              # file creator
        -d date                 # creation date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
        -m date                 # modification date (mm/dd/[yy]yy [hh:mm[:ss] [AM | PM]])*
        -t type                 # file type

                Note: Period (.) represents the current date and time.

                Note: [yy]yy < 100 assumes 20th century, e.g. 19yy

                Note: The following attributes may be used with the -a option:
                A   Alias file
                V   Invisible*
                B   Bundle
                S   System (name locked)
                T   Stationary
                C   Custom icon*
                L   Locked
                I   Inited*
                N   No INIT resources
                M   Shared (can run multiple times)
                D   Desktop*

Note that SetFile could be VERY powerful when used in conjunction with find(1)...

Where should I put new shell commands and files?

> Does it make more sense to copy SetFile into /usr/bin or to > add /Developer/Tools to the UNIX search path?
Personally, I added /Developer/Tools to my path. Since the OS vendor (Apple) decided to install it there, I figured that something else might be expecting to find it in that location, and I might break things by moving it.
Although there's nothing inherently wrong with copying new binaries to some common location, /usr/bin usually isn't the place to do that. By definition, /bin and /usr/bin hold the system commands that came with the operating system. If you start changing or adding to those, then you've sort of compromised the integrity of the OS -- it may no longer behave as advertised.
Under BSD-like Unixes, you generally add new things to /usr/local. New commands can go into /usr/local/bin, new applications can get their own directories like /usr/local/postfix, and custom settings and preferences can go into /usr/local/etc.
There are many advantages to this. For instance, if you upgrade your operating system, the installer can (and will) make whatever changes it feels are necessary in /bin and /usr/bin, but will leave /usr/local alone.
Likewise, you can typically backup your /usr/local, copy it to a freshly installed OS, and trust that you've only moved YOUR changes, without messing up the underlying OS.
Conversely, a new user can sit down at your computer and peek through /usr/local to see what makes your computer different and unique; they can feel safe in assuming the /usr/bin and so forth are "standard" for the operating system.
Of course, all of these things relate to adding programs that are supposed to be available system-wide (to all users). If you want to add some things just for yourself, then the normal place would be in ~/bin (ie, /Users/lyona/bin).
See man hier for additional info...

How do I change my PATH?

	> > Then figure out how to edit the path for that shell. See
	> > http://wolf.bi.umist.ac.uk/unix/primer.html#item3
	> > for assistance. I'm sure there are other, better web
	> > resources too.
	> 
	> That's the part that has me stumped. I'm using tcsh.
	> 
	> Here's my existing path:
	> 
	> [localhost:~] aaron% echo $path
	> /Users/aaron/bin/powerpc-apple-macos /Users/aaron/bin /usr/local/bin
	> /usr/bin /bin /usr/local/sbin /usr/sbin /sbin
	> 
	> I want to add a new dir to the end of this string. How? I imagine it's
	> something like this:
	> 
	> set zpath = ($path)
	> set npath = (/Developer/Tools)
	> set path = ($zpath $npath)
	> 
	> ...Hey, it works! I did it myself! Am I a geek yet?
	> 
	> -aaron

I honestly don't know csh (or tcsh) very well. I use bash, ksh, or zsh exclusively. In all of those three (I think), you can set a new path like this:
	aaron$ PATH=/Developer/Tools:/usr/bin:~/bin
...or you can "append" to the current path like this:
	aaron$ PATH="$PATH:/Developer/Tools"
Note that if you're doing that inside of a script or .profile, then you would need to "EXPORT" the new variable, ie...
	# sample .profile
	export PATH=/usr/bin:/Users/aaron/bin:/Developer/Tools:.
--MZ


Copyright © 2000-2008 Inside Mac Media, Inc. All rights reserved.
Apple assumes no responsibility with regard to the selection, performance, or use of the products or services. All understandings, agreements, or warranties, if any, take place directly between the vendors and prospective users.
Apple, the Apple logo, Mac, PowerMac G4, PowerMac G5, Xserve, Xserve RAID, PowerBook, iBook, Airport, AirPort Extreme, iMac, eMac, iLife, iMovie, iCal, iPhoto, iTunes, QuickTime, FireWire, iPod, iSight, AppleWorks, Macintosh, Jaguar, Panther, Mac OS, Mac OS X and Mac OS X Server are trademarks of Apple Computer, Inc.