Re: A few requests...

On Sun, 17 Aug 2008 20:21:36 -0400
Grégory SCHMITT <gy.schmitt@xxxxxxxxx> wrote:

> > IMHO you're asking for grief by naming items in a manner which will
> > cause problems with a shell, e.g. by putting single " character in a
> > name. 
> 
> Unfortunately, I don't really have a choice; these files must contain a
> ' or " and I can't change their name.
> 
> And most apps I've used won't accept anything but the standard pairs of
> " or ' (i.e an odd number, or a mix of the two will result in failure).
If the shell you're using to run the application(s) won't handle the 
badly-quoted path, that's one thing. But if the application itself will not do 
so, then what leads you to think that escaping would help ?

What is the use-case ?
 1 or > 1 " ?
 1 or > 1 ' ?
 At start or end or anywhere ?
 Sometimes paired or never ?

You can evaluate some stuff just added (completely us=ntested ATM). Un-comment 
line
//#define E2_BADQUOTES
in emelfm2.h and rebuild, it will probably escape " chars embedded in a path 
where surrounding "" are added.


> 
> > A macro such as you've suggested could be used in commands and
> > actions, but that's not the only case where escaping would need to be
> > applied and interpreted.
> > 
> > There are library functions to [un]escape non-printable-ASCII chars
> > in URI's, but they're not suitable for filepaths, which may validly
> > have UTF-8 or other locale chars > 80H. So I guess it would need a
> > new function to identify and escape all embedded " chars, before
> > surrounding a path or name with "".
> 
> I guess this might be my best hope. I plan to find a program which,
> being given a filepath as a single argument, returns the same filepath
> with escaped characters, and I'll then integrate it in my e2 filetype
> actions; worst case scenario, I'll code it myself in shell-script. I'll
> take any suggestion...
> 
> > > - Would it be possible to have an option (to be specified by the
> > > user, in the config panel) that would define a command to be run
> > > after mounting/unmounting devices is done (and returns 0) ?
> > Create an alias ?
> 
> I'm rather against creating an alias for critical commands such as
> mount and umount, especially since my HAL manager and others rely on
> these commands. Also, the command I intend to use uses X, and I don't
> want mount to fail or return an error message when X is not started. So
> I guess an alias isn't really an appropriate solution for me.
I meant an e2 alias, not a system-wide one.

I'm not sure what scenario you're describing. No X == no emelFM2.

> 
> >  I remember that
> > > some time ago, unmounting a device was followed by an ejection,
> > > which has been removed since.
> > There never has been a check on every entered command, to determine
> > if it's a synchronous 'umount' or an alias for that, and then also
> > run 'eject' if so. There still is an eject added when an unmount is
> > initiated via a mountpoints menu, _and_ if HAL support is built (so
> > that ejectable devices can be detected at runtime). I guess the
> > latter test could be relaxed, and always eject when no HAL support.
> 
> I never build e2 with HAL, so I understand why my devices are not
> ejected. But my first thought would be to never eject anything unless
> specified, since I know a couple of USB mass storage devices won't
> behave properly if sent an eject command.
Ok, good reason to leave it as is.


> 
> Now that I think about it, is it possible to redefine mount/umount
> commands within e2 only, and not system-wide ? That would leave the
> possibilty to add any command after mount/umount, such as eject,
> notification, etc.
As above, that's the alias I was referring to.


> 
> > > For those who will tell me to use HAL, I'll say that HAL sends a
> > > signal whenever a device receives an unmount signal and can't be
> > > used anymore, but doesn't send any signal when the device is
> > > ACTUALLY ready to be removed (i.e. when the writes are done).
> > AFAIK you cannot actually unmount a busy device, manually or
> > otherwise. Don't recall what happens when you try, but probably the
> > umount just fails.
> > 
> > Last time I looked (a while ago), HAL just runs shell commands like
> > umount and eject, and is subject to the same constraints (not busy
> > etc) as if the commands were issued manually by a user.
> 
> Are you referring to a HAL manager, or HAL itself ? HAL doesn't run any
> commands on my computer, and never did.
If you look at the source code, I think you'll find that it does. I forget 
whether it was in libhal or the daemon.

Regards
Tom


--
Users can unsubscribe from the list by sending email to 
emelfm2-request@xxxxxxxxxxxxx with 'unsubscribe' in the subject field or by 
logging into the web interface.

Other related posts: