GUI Fights with Kernel!

[Ehdrian]

Hi!

If I create a script:

#!/bin/sh
cd /mydir
./runme

This should execute the file "runme", but it brings up a text editor instead. The file attributes are read,write, and execute on both the script and the executable.

If I click the file, it pops up in a text editor, and if I type "./myscript" in the shell - it runs fine.

Is the GUI not POSIX compatible?? Why is it ignoring the fact that the file is exeutable? It should run when clicked... should it not?

Thanks in advance!
-=//-\drian Thompson=-

 

[Ehdrian]

OK Here it is:

1. Create the script
2. Chnage the extension to .command
3. # chmod a+x myfile.command

This will work through finder. And...

If you don't want to see the shell window pop up use "Platypus" which gives it a wrapper. I don't know how to use it, but just in case anyone wants to know.

And as a side note:

I find it extremely stupid that Darwin would be POSIX and the GUI is NOT! Why in hell would the GUI ignore an executable bit in the file system??? And on top of that, the EXE file in an application package can be executed by the GUI but is not set as an executable on the file system! This is just ridiculous! If Apple is going to claim that MacOS X is the most advanced OS in the world, maybe they should get some pointers from Sun, Solaris 10, first. At least UNIX and Windows have an OS that doesn't fight with itself. After attempting to develop on this platform, I think I already have multiple personality disorder!

 

[lurk]

I think you are a bit confused here. Posix defines a shell but says nothing about a GUI or how it must operate. When you think about it everything that is interesting in a GUI is totally outside of Posix. Also the EXE as you call it in side of an application bundle does have its execute bit set per posix, when it is actually a traditional executable.

Really, it works just like Solaris in most ways, if you are having troubles you might be misunderstanding something.

 

[Ehdrian]

Having to set an executable bit AND have a .command extension is very odd. The .command extension is for the GUI and the executable bit is for the GUI and the shell.

Whereas in all WMs I have ever used, the kernel knows to interpret the file based on the "#!" macro as long as the execute bit is set. Many other GUIs follow the same rules as the shell such as KDE, Gnome or CDE. Whe I double ckick something it checks the attributes first, then it looks for file asociation.

It seems that Aqua and the shell have different ideas on how things should be done - and they are not completely compatible. It's almost like two completely different OSs (Mac 9 and UNIX) were thrown together and patched until they cooperated. It also seems like Aqua has more authority than the kernel when cliking to execute files - this is backwards.

Under normal kernel operation, the file would be executed and the #! macro read by the kernel and interpreted using that program. It shouldn't matter which GUI you are using or what extension you have whether it be a BSD or SysV running KDE, Gnome or whatever WM.

Just my opinion.

 

[Mikuro]

It's almost like two completely different OSs (Mac 9 and UNIX) were thrown together and patched until they cooperated.

"Almost"? Or were you being sarcastic?

I don't see this as an inconsistency, but then again, I'm not coming from other Unix platforms. The way I see it, the command line doesn't open files. It just executes commands. e.g., if I say "./someimage.jpg" in Terminal, it's not going to open that file in my image viewer of choice the way it would if I'd double-clicked it in the Finder, and nobody would expect it to.

So naturally it'll execute any file that it can, regardless of the file's type. The executable bit tells the command line which files can be executed. It doesn't change the type of the file, though. The Finder relies on file types, because it's opening files rather than just executing them.

In short, double-clicking a file in the Finder is not equivalent to something like "./myfile" in Terminal; it's equivalent to "open ./myfile" in Terminal.