creating your own tools
 

This may be obvious to many but, for those who are new to Unix, I wanted to mention the process for creating your own "commands" (really just executable shell scripts).

First this is a follow up to my post on an earlier thread and may make reference to information therein:

http://forums.osxhints.com/showthrea...s=&threadid=92

At the end of that post, I metioned creating a "trash" command to always (as far as I can tell) empty your stubborn trash with a one-word command. Since a couple of people emailed me asking for the details, I will try to describe the process as my example.

Again, there are some one-time preliminary steps. We will utilize the same directory structure that I created in the former post.

Use cd to change to the directory ~/Library/init...

cd ~/Library/init

Then create a directory inside the init directory to hold your executables (a standard name is bin)...

mkdir bin

Open the pico editor to create a file called trash (that will be the name of our command -- if you want a different name for the command, use something else) by typing...

pico trash

You will now be in the pico editor. Enter the following three lines which will comprise our trash command...

sudo chflags -R nouchg ~/.Trash/*
sudo chflags -R noschg ~/.Trash/*
sudo rm -ri ~/.Trash/*

Make sure that there is a return after the final line and use ctrl-x to exit pico. At the prompt, indicate that you wish to save and hit return to save the file with name trash (or whatever name you used in the initial pico command above).

A brief moment to explain what the commands above do. Basically, the first two lines turn off the immutable flag for every folder and file in the trash at both the user and system level respectively. The immutable flag could become set by a user locking a file, or by the system thinking a file is currently in use, or possibly through other more mysterious means (maybe dragging something to your OS X volume while runing OS 9). After any locks have been removed, the third command removes everything in the trash, without regard to permissions or ownership.

After saving the file, there are a few more things that need to be done. You need to set the file to be recognized as an executable. I will do this using the chmod (change file mode) command...

chmod 755 trash

This will allow the owner (you) to run or modify the command. It will also allow any other user to run the command (but not modify), assuming it is placed in their path (explained below). All users will still need a sudo password.

I used these particular permissions because I want access to the command even when I am logged in as another user. If you have security concerns, you can use "chmod 700 trash" instead, which will give you access to the command but no other user will have access.

Now for setting your path. To explain quickly, path refers to a list of the directories where your terminal will look to find a match for any command used in the terminal.

To set you custom path, change directory to the tcsh directory created in my earlier tip on aliases (mentioned at the beginning of this post).

cd ~/Library/init/tcsh

Before, we created a file called aliases.mine in this directory. Now you will create a file called simply path.

pico path

Once in the pico editor, type the following line...

set path = (/Users/shortname/Library/init/bin $path)

Replace "shortname" with your actual shortname (this will be the name shown for your home directory inside the Users folder).

As usual, place a return at the end of the line, hit ctrl-x and save the file as path.

You are now done. If you close your terminal window, and reopen a new window, you should have acces to your new trash command. When your trash can is being stubborn, open the terminal (or just leave it open always!), type trash, enter your password and gone...

Sort of. One additional piece of info. As a precautionary measure, I created the above command using the -i flag in my rm command. (look above and you will see this in the third line of the trash file -- sudo rm -ri ~/.Trash/*)

The -i flag tells the computer to ask (y/n) before finally removing each file. This is a great extra precaution (especially while you are still verifying that your newly created "command" is working properly). However, if you delete an .app package, you will be asked to confirm for every resource contained inside. Any time the trash is very full, getting confirmation for each file is overkill (in my opinion).

For that reason, I duplicated the above process to make another command in my ~/Library/init/bin directory called "trashnoi" (or trash command without the -i flag). Everything is the same except, in creating the three line command, replace this...

sudo rm -ri ~/.Trash/*

with this...

sudo rm -r ~/.Trash/*

No more confirmations. I use the safer version most often, but the noi version when I am deleting a stubborn folder with a lot of contents.

So, if a simple alias doesn't meet your needs, you can always use the approach above to an easy-to-remember "command". I use a bunch of 'em. For a new user (or even an experienced one), it's quicker than retyping several comands each time and eliminates mistakes. Just remember to set the file you create to executable using the chmod command described above.

Hope you all have as much success (and use) for this shortcut as you did for command aliases. Thanks to those who emailed. Enjoy...

Maclaw

In a similar vein, I was trying to come up with a script to move material to the TRASH instead of using rm. I had thought that something like mv " " ~/.Trash might work, but the .Trash directory only seems to appear once something's already in the trash, and then disappears once the GUI trash has been emptied, so I have no idea how to go about doing it. Any suggestions? Thanks.

this all seems like bad mojo to me

what problem are we trying to solve?

what are the requirements?

how come i don't have stubborn trash?

let's try and find the cause of the problem, rather than spend a lot of cycles on band-aids.

Ah, mervTormel, we meet again.;) All I'd like to be able to do is type a command, say tr for trash instead of rm for remove. This would let me move a file to the TRASH rather than completely VAPORIZE it. That way I get a second chance if a) I mistakenly get rid of the wrong thing or b) it turns out I really DO need that file after all. Ok, so I'm paranoid AND a packrat. Any ideas?

ideas?

i had the idea for bouncing laser light off of an encoded plastic platter to play music when i was twelve playing pinball in a skanky air force base cafeteria in layton, utah.

i had the idea for electronic paper a few years later. they're still working on that idea.

as for the tr command, it's already taken by the tr command, sorry.

but i do have an idea for you.

- create a folder in your home dir, or somewhere under there

let's say, for grins, ~/scratch/myAlmostTrashButImNotQuiteCertainYet

then, make an alias (tcsh) that goes something like this

# alias ztr 'mv \!* ~/scratch/myAlmostTrashButImNotQuiteCertainYet'

now, if you find an offending file named foo

# ztr foo

even if this is on another partition, it will be whisked away from source to target, whisked meaning deleted. the mv implementation for volume to volume moves equals 'cp file targ ; rm file' i believe

***
please test this thoroughly, as i haven't
***

why the z?

it is vile to alias a true unix command, like cp, rm, ls, because you may connect remotely and not have it and get yourself into trouble if you rely on your rm alias to be rm -i to ask you if you want to delete something.

how many true commands begin with z?

perhaps a few, but if all your aliases begin with z, you run little risk in stomping on true commands, and you get in a good habit of not relying on your preferred environment when working in remote environs.

for example:

merv,

ztr rocks in concept - but it needs a bit more devepment for the mac. The mv command when moving across partitions or filesystems uses cp and rm (copy and remove). This can create an issue with Carbon apps, Classic apps and docs generated by these apps. The resource forks are not copied with cp. This will render the files potentially useless (and thus not worth recovering). MvMac (installed at /developer/tools with the dev tools) would be a better option.

Hugh

PS - I think I've learned more Unix with tonights bout of insomnia than I have in the last couple of months. Thanks.

Wow, thanks guys! I've recently become fascinated by the Unix side of things, so this stuff is great! I'll look into the above ideas. What about this (bear in mind I obviously have NO idea what I'm doing) I could create a hard link to my ~/.Trash folder the next time it appears (this happens when something is put in the GUI trash), then send stuff to the hard link so even when the .Trash folder dissapears (when the GUI trash is emptied), it would still end up in my (GUI) Trash? Would this work, or would it just cause my computer to implode?

Ahhh, but it is far more complex. I considered proposing that exact line when discussing this with Titanium Man earlier, namely using an alias containing mv \!*, but there are two problems...

1. As stated, you would need to use MvMac, not mv, to ensure compatitbility with Mac data files (unless you trust yourself to only move things that have no resource fork). MvMac requires installing the developers kit which Titanium Man may or may not have (but could get).

2. Mv is a destructive process, meaning that if you move something to a location where something by that name already exists it will simply overwrite the existing version.

Given those limitations I have been using the following two aliases to solve this problem on my own system...

alias delete 'MvMac \!* ~/.CLI-Trash'
alias empty 'rm -ri ~/.CLI-Trash/*'

However, you must first create the diretory ~/.CLI-Trash or your first move will actually act as a rename! Plus you must have the developer tools.

Though effective, this solution simply acts as a totally seperate CLI trash can. Does anyone know how to do the same by interacting with the GUI trash can triggers?

As a unix type, I have little knowledge of how the GUI communicates and I see 3 main problems that I cannot resolve...

1. The .Trash file is only created when something is placed in the desktop trash can. Sure I could create it manually with mkdir but the GUI will not recognize my creation as its trash directory. In fact, when placing something in the GUI trash afterwards, I get the error that the trash is already in use.

2. Even if there is any existing .Trash file (because something is in the trash can), how do I get the GUI to see things that I add from the command line. It doesn't happen on it own. The trash can only recognizes contents added from the GUI.

3. If I do an rm to empty .Trash from the CLI, how do I let the GUI trash can know it is empty??

The point is, it would be nice to have all of my trash in accessible in one place and have the GUI and CLI truly interact.

mervTormel

I appreciate your levity, but I wanted to mention something about the stubborn trash issue. Maybe you haven't experienced it, but you probably will. In most cases it is not indicative of a problem, just normal Unix flags and permissions doing their thing. I gave examples of when this might happen. Maybe you have a bunch of files that are locked -- the trash won't delete these. Maybe you have moved something from your OS 9 partition to the root level. Since the move was done in OS 9, there is no associated owner so the system will associate the ownership of the root directory (that being root). Consequence -- the trash won't delet it. If you spend any appreciable time on these boards, you will hear people complain "it's my computer I should be able to do whatever I want". I simply explained what is happening and how to correct it (if you should choose to do so).

You make it sound like some nefarious patch job going on. It's no different than in OS 9. If you have a locked item in the trash, or something that for some reason won't delete, you can delete it by unlocking it first (that is all that the chflags -R nouchg command does, a bulk recursive unlock). Or you can use a short-cut (is it holding cmd or something??) Anyhow, the above script is simply a shortcut to force empty your trash since Apple did not include that OS 9 feature in the OS X GUI.

There is one oddity in OS X for which a "band-aid" is needed. If you preview an mp3 or mpg in the finder, or certain other activities, the system is prone to continuing to think the file is in use after being trashed. Sure, you could log out and log back in and then trash it. Or you could do what I explained above and then just type trash. You decide which works better for you (i'll stick with my way, thanks.)

Although the experience has been uncommon for me, judging by my email, you may be the only one who has never had "stubborn trash". Besides, it was just an easy example that I picked to illustrate the greater concept of creating a folder of mini-scripts (bigger than aliases, smaller than full-blown applications) that function as useful commands.

Hugh,

Sure enough, cp isn't going to be a good solution for resource-forked files.

Thanks for pointing that out. And MvMac is a great find.

Learning Unix is prolly a lifetime endeavor, so you had prolly oughta like it a little, eh?


TiMan,

I'm not too sure, but I think a hard link to a folder, like the .trashes that gets deleted and recreated, is going to leave you with a lot of dangling hard links. Your hard link is still going to exist and it points to a block on disk that will never be seen by the finder again. The finder'll create a new .trashes, unaware of your hard link.

I'll have to think about that some more, though.

Let us know your results.



Maclaw


I consider this just so much twaddle.

If you put items in your root directory, you suffer the consequences.

Unix is a sophisticated system, and like all systems, can be unforgiving, and likes to see things where they belong. Without order, chaos.

I will have none of it.


--
These are my opinions. If you don't like them, I have others.

Look, I'm not going to go back and forth about this. I simply wanted to leave an explanation lest there be any confusion.

In my mind this forum is called UNIX-Newcomers. Yes there is an expected order under UNIX, which is why (as I stated), I rarely have the need for my own command.

I happen to not be a UNIX newcomer, however, I am not so arrogant as to tell a NEWCOMER coming to these forums for help that "if you make a mistake while learning the Unix directory -- too bad." Maybe you want anyone who isn't a UNIX professional to throw their computer out the window because they committed the cardinal sin of putting something in their root directory (a location, I remind you, which held no unique position in the former Mac OS). Many people are converting from OS 9 and don't realize why it is that you do or don't do things.

I spend some time on the NEWCOMER forum to help these folks, not to mock them or deride them as you seem intent on doing. For people who are on this NEWCOMER forum to learn, an explanation of why something happens and how to avoid it is not "just so much twaddle".

I am hoping to dispel the UNIX tradition of people in the know looking down on people trying to learn. You remind me of the folks that used to hang out Usenet back in the late 80's. If your looking for a culture of derisiveness, maybe you should run a hotline server. But that is not what the Mac community is about.

Maclaw

Regrets. I certainly didn't mean to sound mocking. It's just my way.

By all means, go ahead and

# sudo mv /bin /binary


A great way to learn is to do something, watch it break, and figure out why and discover how to fix it.

Unix is a tinkerer's paradise. It's also a salty witch.

i just want to refrain from encouraging bad habits and form.


let us know if you get your trash manager working well.

regards,

-mt

merv,

Have I offended you? Apologies if so - no harm intended.

/developer/tools - contains several unman'd mac only unix tools. If you type the name with no qualifiers they spit out sort of a mini man.

I like to add the whole shebang to my path via: /usr/share/init/tcsh/login (just be sure to back up the original.)

Hugh

hschickel --

are you just trying to add the unix commands installed by the Developer Tools to your path?

you mentioned backuping up the originals so I may be confused about what your are attempting. On my system, the Developer Tools were installed in the directory /Developer/Tools

In order to permanently add this to your path, simply create a file called path in the directory ~/Library/init/tcsh (or open it if you already have it). There you can add a reference to the location of the tools without moving anything. For example, using the following...

set path = ($path /Developer/Tools)

would set your path to the default path PLUS anything in /Developer/Tools. You can add as many directories as you want if you keep custom installations in a particular place. I added ~/Library/init/bin for executables I have personally created. I also wanted my current working directory (wherever it happens to be, to be included in my path). CWD is represented by a period. So my path looks more like this...

set path = (. ~/Library/init/bin $path /Developer/Tools)

The order in which you list things is the order in which the shell will try to match your command. For instance, I was testing out a new version of pico so I wanted the command pico to call my new version not the default system version. While testing, I placed the new version in ~/Library/init/bin which is located before $path in my path and so my version would always be found before the default system version. You can order things however it suits you.

Of course, if you already knew this and I completely misunderstood what you were going for... my apologies :D

not at all. i was just waxing philosophic.

yep, you can add the devo tool dir to your path, or just create a symlink for the tools you use in your

~/bin


a ~/bin is handy for the personal tools you write

i believe ~/bin is in your path by default.

Actually,

I stumbled across this file /usr/share/init/tcsh/login before I learned the proper way to modify my path. The cool thing about modifying this file is that the path is now altered for all users on the system.

Your way is technically correct of course - but I did not have these forums or even a unix book as a resource when I first got sick of typing /developer/tools/CpMac to copy something. :)

I guess there is just more than one way to skin a cat (philosophically speaking of course.)

Hugh

Edit: mod to file

MT- that hardlinking/symlinking a directory to ~/.Trash didn't work for me. While there's something in the (GUI) trash I can create a symlink to ~/.Trash, (with the -s argument) move things to the symlink, and they end up in the GUI trash just fine. However, when the GUI trash is emptied, ~/.Trash dissapears, and there's nothing left to be linked to. I tried to do a hardlink instead, and was told something about being unable to perform that operation or something. Shrug. As for putting MvMac in my path, Maclaw, I had read in your post about setting the path. I hadn't done it because my path file had already said set path=( $path /usr/X11R6/bin ). But you can add a second line to that? Cool, thanks!

*** Security - Search path issues
 

Security - Search path issues

From O'Reilly's "Essential System Administration, Second Edition" Aeleen Frisch, 1995


"It is important to place the current directory and the bin subdirectory of the user's home directory at the end of the path list, after the standard locations for UNIX commands:

$ echo $PATH
/sw/bin:/sw/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/$HOME/bin:.

This placement closes a potential security hole associated with search paths. If, for example, the current directory is searched before the standard command locations, then it is possible for someone to sneak a file named, say, ls into a seemingly innocuous directory (like /tmp), which then performs some nefarious action instead of or in addition to giving a directory listing. Similar effects are possible with a user's bin subdirectory if it or any of its components are writable.

Because of the potential for much more damage, the current directory should not even appear in root's search path, nor should any relative pathname. In addition, none of the directories in root's search path, nor any of their higher-level components, should be writable by anyone but root; if one is, then someone could again substitute something else for a standard command, which would be unintentionally run by and as root."

very true. but the uncool thing about it is...

1. if you reinstall your system, you have to rember all of the system modifications that you made along the way and put them back. i only have to back up and restore my Users folder to put all my mods as they were.

2. modifying your system files is also a very easy way to bring your computer to a screeching halt. especially while you are still at the stumbling stage!! i think this is the point that merv was trying to make earlier.

I am not completely opposed to tinkering with config files (in moderation). Just make sure that you ALWAYS use "cp file.conf file.conf.bkup" (or CpMac if needed) so when you screw up the original, you can always get things put back into place. That, of course, assumes that you don't screw it up so bad that you can't even get access to your files.

Finally, and most important -- Always read the readme!

If you found your way to the directory /usr/shar/init/tcsh then you would know that the first file in that directory is called README. Inside that README are all of the instructions that tell you NOT TO DO WHAT YOU DID!!

In relevant part, it explains...

Shame on you, Hugh :p

maclaw,

exactly! very good points.

these are issues that are illuminated in the first few chapters of most good UNIX books.

be sure to read the above post about search path security issues.

sincere regards,

-mt