Re: Nautilus should ignore the +x bit

[Mike Hearn <mike navi cx>]

On Wed, 11 May 2005 21:07:48 +0200, Danny Milosavljevic wrote:
> Hm, in my shell scripts, I have one(sometimes maybe more) main
> shellscript that has +x and tons of "library" shellscripts that don't
> (which are sourced by the main shellscript). So from a developer
> standpoint the "library" shellscripts aren't executable programs and
> when I click on them I want to edit them or I misclicked :)

Sure but typically for end user visible shell scripts, they'll be
programs. If they aren't then the systems guts are leaking and that needs
to be fixed.
 
> Well, at least +x its nice to have because its very clear to the
> user/admin/... what should be executed and what shouldnt (although it
> doesnt do any good because it just can be changed, yeah :)).

They're useful for coloured ls listings it's true :) But from the
perspective of a GUI, there is no visual representation for the +x bit
anyway. I'm not suggesting it should be ignored by everything, just
Nautilus, as realistically that's the only time this could cause the user
problems.
 
> > That'd certainly be a nicer way of handling tarballs. Alternatively
> > some MacOS X style DMG disk image that the desktop understands and can
> > mount would be good (but you need some way to mount them without
> > root).
> 
> GnomeVFS comes to mind

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.

> > 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íthout 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.

> Well, from a puristic standpoint the downloading programs are broken /
> unsuited for downloading binaries, because having nautilus unbreak the
> permissions (or worse, ignoring them) which the admin set isnt going to
> make him happy, at least. Though the user would like it, I'm sure :)

Why would the admin care? If the user can't write outside their home
directory it doesn't make much difference anyway. And remember that right
now an awful lot of Linux users are both the end-user and admin. Let's not
go down the Windows mentality of writing off hard problems by saying "If
it still does not work, consult your system administrator" :)

> +----------------------------------------------------------------------------
> | !   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 ]
> +----------------------------------------------------------------------------

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. 

> 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.
 
> 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.

thanks -mike