Re: A few requests...
- From: <tpgww@xxxxxxxxxxx>
- To: emelfm2@xxxxxxxxxxxxx
- Date: Mon, 18 Aug 2008 09:20:41 +1000
On Sat, 16 Aug 2008 22:26:01 -0400
Grégory SCHMITT <gy.schmitt@xxxxxxxxx> wrote:
> I thought of a few features/bugs that might be interesting for e2:
>
> - Escape special characters in the filename.
> AFAIK, e2 currently offers the possibility to surround the filename
> using quotes (") by calling %f, or disabling the quotes (%%f). I have
> several files with filenames that contain either a " or ',
> leading to the command associated with the filetype not being properly
> executed. How difficult would it be to design a new variable (such as
> %e) that would escape any special character (such as " ' ? *...) with
> a slash ?
For e2 internal file-operations at least, there should be no need to manage
anything.
For a path supplied to an external application, I would hope that standard
shell behaviour applies i.e. surrounding double-quotes work the same as
escaping all special chars inside the quotes, any number of ' characters inside
double-quotes will be ok, an even number of " inside "" will be ok, an odd
number of " inside "" _will_ be problem. But I suppose there's no guarantee
that every application will behave like this. Similarly, I don't know that
escaping will be handled by every application.
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.
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 "".
> - When executing file.info on a file with a filename containing spaces,
> the description given by "file" is correct, not the one given by the
> mime type (obviously, the filename variable is not quoted).
This was fixed a few days ago.
> I quickly looked at the code and located two different pieces of code,
> in e2_utils.c and e2_file_info_dialog.c. What puzzles me, Tom, is that
> if e2_utils_get_mimetype() fails, there's a fallback value (using the
> command file), and in e2_file_info_dialog.c, there's again a fallback
> value (using file again, but with different parameters). Isn't it
> redundent code ?
Essentially, it first tries to use xdg-utils(1) to discover a mimetype, and if
that fails, it tries again using file(1).
>
> - 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 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.
> 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.
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:
