Don't get too hackeresque, we seen that movie. When you plug a usb drive into a system, it can be automounted and some systems like windows can autorun things on it. Not being a mac hacker, I am not sure how to set up either.
Once it is mounted, for any script run, its location will discernable from $0 and $PWD, and possibly $PATH, as the only way to run it is with an absolute path, a relative path or a $PATH dir entry. The apparent script location may not be a real path, if it was run through a symbolic link, but you can run realpath to find out or chain up .. until root (inode .. = inode . )
In a unix file system:
- there are many types of inode: directory, flat file, symbolic link, named pipe, raw device, cooked device and maybe a few I forget. Read the source, Luke, and man pages, too.
- A directory is essentially a list of entry names and their inode numbers -- nothing else!
- The inode numbers are relative to the device.
- The root tree starts on the root device, but you can mount file systems over directories, hiding those directories and all that might be in them on the parent device, and establishing another device for that sub-tree. You can see some oddities in such a neighborhood in the ., .., directory's entry name inode numbers, as I recall. df and mount show you all the mount points including root, read off root!
- One device can be mounted upon another.
- Some variations of ls and find show inode numbers and device numbers.
- A symbolic or soft link contains a path, relative or absolute, to a replacement entry. The ln command creates both
- hard links (two directory entries with the same inode #, like /. and /..) and symbolic or soft links or sym-links (-s), rather like windows shortcut file *.lnk.
- The rm command is a wrapper for unlink(), as a file is not really removed until all links, directory entries to the inode, are destroyed (the inode has a count, which you see on ls -l), and even then the inode is parked somewhere like lost and found if it is still open at remove time. SOme tolls remove temp files after openeing them, so there is never any collision of names, cleanup, prying or interference.
- Only the system can hard link directories (every child directory's .. is another link on the parent directory inode, plus . and its entry in the grandparent), so symbolic links on directories are very popular. Not sure offhand about hard links on other inodes! Windows NTFS allows hard links, too, which I noticed under CygWin just recently! I am not sure if Mozy double-charges me to back them up!
- If I use a symbolic link, find -type f ill miss it unless I say -follow. The ls option L makes it punch through sym-links. Using a trailing / or /. forces a trip through to the real inode, too.
- NFS and its buddies can mount remote files in the local tree. All calls just wander over to the real system on the net.
- Traditional simple file systems are initially configured with just so many inodes on the device, and you can run out.
- Complex file systems can be runing interference behind the facade to make many devices into one, slide space from one place to another, add ACLs for extended permissioning, mirror, RAID, quota, .... They can manufacture inodes on demand. They can make for a slow reboot from any ungraceful shutdown, too. SAN systems may use NFS or have proprietary connection hardware and protocols. Solaris Client file systems can use local disk space as a persistent cache for NFS mounts. And so the head starts spinning.
- Welcome to UNIX file land.