Re: Nautilus should ignore the +x bit
- From: Sebastian Kapfer <s kapfer_usenet gmx net>
- To: nautilus-list gnome org
- Subject: Re: Nautilus should ignore the +x bit
- Date: Sat, 14 May 2005 12:34:24 +0200
On Wed, 11 May 2005 20:50:32 +0100, Mike Hearn wrote:
> I'd rather avoid that if possible, for the reasons Miguel expressed on
> his blog. Just allowing users to mount things without root is fine: for
> desktops it can't hurt (whereas for servers maybe it can). This is the
> way MacOS X does it, AFAIK.
That's the way to go.
>> > No I think that'd be OK, though the net result is that the user
>> > doesn't
>> > have to set the +x bit _which is exactly what I'm proposing_ :) Why
>> > is
>>
>> Yeah, but w�out overriding unix permissions all over the place ;)
>
> Only Nautilus would ignore them. You don't want to change the actual
> POSIX APIs or the kernel as that's a semantic change that'd break more
> than it's worth. I think it's OK for shell users to deal with the +x
> bit, because we expect command line users to memorize tons of other UNIX
> stuff anyway. But for GUI users it should just DWIM.
I don't think Nautilus should just ignore the +x bit. The flag represents
a conscious decision by someone (be it the site admin or the user) to tag
this file as something they want executed. The process of tagging should
be easy for the user, which makes look
>> +----------------------------------------------------------------------------
>> | ! File is not a known program
>> |
>> | The file "installer" you clicked is not known to be an executable
>> program.
>> | However, by looking at the contents it seems that it should be. |
>> | [ Cancel ] [ Fix and Start ]
>> +----------------------------------------------------------------------------
like a good idea to me.
> Yes, something like that. Though "Fix and start" makes it sound like
> something is broken or wrong or the user did something bad. But this
> isn't the case.
Then rephrase it. The dialog isn't supposed to be about fixing.
+----------------------------------------------------------------------------
| ! File is a program
|
| The file you're trying to open seems to be a program.
|
| Do you want to run it instead?
|
| [Run it] [Always run this file] [No, edit] [Cancel] |
+----------------------------------------------------------------------------
Where "always" would set the +x bit, so the dialog won't appear next time,
and runs the program.
"Run it" would use a workaround trick to run the program (like calling
ld.so for ELF, wine for PE, sh for shell stuff, python on a Python
script...)
This button is important for "noexec" filesystems or filesystems which
don't carry UNIX file permissions. (Some distros like to mount CD-ROMs
noexec, which can be frustrating to newbies, because Nautilus tries to run
setup.sh, but not surprisingly fails.)
I also think the edit button is useful, for those who just like to look at
a scriptlet they just got from a colleague.
Cancel does the obvious -- nothing.
I think this would be a good compromise -- die-hard UNIX hackers will
figure out what's going on, and newbies have a chance to run something
without touching the terminal.
>> btw how are mono executable files handled ? Windows PE exe files ?
>
> EXE files are associated with the wine/mono programs and are therefore
> treated as data files.
You can also make the (Linux) kernel recognize these things as being
executable and invoking the correct interpreter for them. Look up
binfmt_misc. I don't know about the BSDs.
>> freedesktop comes to mind
>
> Well, making a specification there doesn't magically rewrite all the
> programs. It's an awfully hard way of doing something very easy.
I would like to see such a dialog deployed desktop-wide, and if not that,
at least for all of GNOME. Opening files isn't specific to Nautilus.
--
Best Regards, | Debian GNU/Linux ---> http://www.debian.org/
Sebastian |--------------------------------------------------------
| mailbox in "From" silently drops any mail > 20k
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]