hp: is this a nautilus drag issue?

I guess this is a terminal issue. Question is do we want to assume
that DND'd text is going to land in a shell. You could also DND some
text into a text editor or something. Terminal doesn't know what sort
of app is running inside it. If I dragged a paragraph of text to mutt,
I might get annoyed that all the spaces were escaped.

Exactly. Maybe it's enough if gnome-terminal "detects" shells and
escapes only if that is the case.

There's no way to detect a shell that I know of.

I don't really have a clue how to fix this. The terminal doesn't know
what sort of program is running inside it.

*** Bug 171995 has been marked as a duplicate of this bug. ***

*** Bug 309042 has been marked as a duplicate of this bug. ***

Is this not going to get fixed?
The drag & drop feature isn't very useful if it only works for certain files.
Dragging files to the terminal on OS X escapes the name no matter what's running
-- just tested on pico and vi.

Joachim: No, because there is no way of knowing when it should be escaped and
when not. It cannot detect what program is running, so only option would be to
always escape or never escape. Sometimes I'd want filenames to be escaped,
sometimes not... I currently use "" and put the cursor in the middle for when it
should be quoted. The wontfix is because always escaping wasn't acceptable to
the maintainer + there is no way of fixing this.

I would really like the WONTFIX decision to be reconsidered. Having the filename
quoted would be a better default, because the shell is the most common app run
in the terminal, having quotation marks around a filename in a text editor
doesn't break anything (they could actually make the text file more readable)
and many apps would probably parse the filename correctly even with quotation marks.

*** Bug 309705 has been marked as a duplicate of this bug. ***

Instead of half-measures, why not work on allowing the terminal to report what
is running in it?  That is not my area of expertise in the least (so I know not
how difficult that would actually be), and I'm sure the question is well beyond
the scope of this bug, but making that change seems like a win-win for everyone,
and not just for just this specific bug.

Wayne, from comment 4:
> There's no way to detect a shell that I know of.

That comment is from the maintainer at that time.

What about having a user option in Terminal prefs to either escape or not?
Or what about drag to escape, and ALT-drag to not escape?

*** Bug 313783 has been marked as a duplicate of this bug. ***

*** Bug 327199 has been marked as a duplicate of this bug. ***

Hi guys,

I think the key here is what and where we are dragging from.  

1)  If I drag a file (or folder) from nautilus, it should be quoted, with a
        space at the end.  
2)  If I drag text from anything else, say gedit, it should arrive unchanged.

Is there enough information during the drop to make a distinction whether it is a file or not?  Or secondarily whether it is from nautilus or not?

Also, even if there is no way to find this out I still vote for quoting the text always.  I drag and drop files several times a day to the shell, but never have ever drug text to a console app.  Not exactly a scientific study, I understand.  ;)

Expanding on comment #17, Nautilus (and any other file manager worth its salt) uses text/uri-list for file drags.  The terminal knows this and handles it.  So we're not at all talking about escaping all text drags.  Just file drags.

I don't really see how not quoting or escaping could possibly be beneficial for all cases in any general program.  If I drag three files, and they're not quoted or escaped, and you concantenate them together with spaces in between, that's massive ambiguity, shell or not.

There have been at least two duplicate reports.  People have continued to make noise even after the WONTFIX.  Both Konsole and Terminal.app quote file names from a drag.  To me, all of that adds up to this: People want this feature, and they're willing to accept quoted file names when dragging to mutt to get it.

But Shaun, a URI is not the same as a filename.  So, do you mean vte is already converting the URI to a local file name?  I cannot see such code in vte.

Testing it now, dnding a file on an ssh folder pastes the URI:

  ssh://cs.toronto.edu/u/behdad/b07

If there is a way to identify a filname, I'm with quoting it.

Behdad, the code is actually in gnome-terminal, not vte.  It runs through each URI in the list and calls g_filename_from_uri to try to turn them into file names.  If that fails to give a file name, then it just uses the URI.  Then it concatenates them all together with spaces in between.  It's pretty basic code.

I'm attaching a patch that could turn this bug from WONTFIX to FIXED.  For each URI, if (and only if) it contains a space, it is wrapped in "double quotes".  Unless the URI also contains double quotes, in which case it is wrapped in 'single quotes'.  Unless the URI also contains single quotes, in which case, it is wrapped in double quotes and the internal double quotes are quoted according to an arcane mechanism that will work for both sh and csh.

Created attachment 59532 [details] [review]
Implement file name quotes

In my comment in that code, change the first "escape" to "accept".  There should be spell checkers for comments in C files. :/

Shaun, I expected to see some combination of glib calls to escape the thing, but seems like there's not much in that area.  Anyway, I prefer this logic more:

  - Quote using "" if at least one of these is found: " \t\n\r'\"()[]*?`" and probably a few others.  That test can be performed using strpbrk.

  - Escape any of "\"`" (any more?)

Trying to do Python-style auto-single/double-quoting does look that appealing to me at least.

Re: 18
>  Both Konsole and Terminal.app quote file names from a drag. 

And don't forget dragging from explorer to cmd.exe or command.com from Windows!  I used this daily when still using it. 

All these platforms together are about 98% of the PC user-base.  I can't really see a significant advantage to doing it differently.

As for the implementation, I suggest that it should probably be as simple as possible.  If a person is dumb enough to put various expansion chars in the filename, let them worry about it.  The vast majority of the time, it wont be an issue.

I'm not dumb, and I use all kinds of characters in my file names when ripping music from my CDs.

Sorry, didn't mean to imply you were dumb... however the double quotes should handle the majority of these already.   Single quotes would handle everything but other single quotes, right?  I've ripped 500 cd's and don't remember any titles with quotes in the name.  

Oh well, I still lean towards simple, but if it works intuitively it's no problem.

Good point about single-quotes.  Yes, using single quotes makes it a lot easier.

It's not about having quotes in file names really, brackets and parantheses are quite common and the do need quoting.

I have files when single quotes in the name, basically because it doubles as an apostrophe.  For instance: "07 Let's Get It On.ogg".  Question marks are also common, such as "06 Donde Estas, Yolanda?.ogg".  I don't mangle file names for music.

So my patch shouldn't be used, but it does show how easy this is, from a code standpoint at least.

Maybe we should just always quote, and escape quotes with backslashes, and let tcsh users suffer when they have file names with double quotes.  (For the record, I'm a tcsh user.)

Quoting with single quote is a bit easier, as the only character that needs to be escaped is the single quote itself and the escape character (backslash).

Really?  At least in tcsh, single and double quotes do the same thing, as far as I know.  I do have more files with single quotes than double quotes, so using single quotes would mean escaping the quote more often.

In /bin/sh and compatible shells, $ and ` are expanded in double-quotes, but not in single-quotes.

about the running an application in a terminal state. multi-gnome terminal colorized the tag label, if an application is running (a feature I like to see in gnome-terminal too). So there seems to be a way to detect wheter a shell is running of e.g. gcc/mutt or whatever runs.

What do you mean by "tag label"?

sorry, I mean *tab* label. multi-gnome-terminal is able to show wheter an application runs in a tab and wheter there is new output since one last visited the tab. So it seems to be able to follow whats been executed inside the terminal.

Didn't it just color the text on the tab if there was new output since you last viewed the tab?  That doesn't really mean it can tell what's running.  It can just tell when stuff is printed to stdout/stderr.  There is a difference between writing to stdout and putting text on the screen using something like curses.  But it can't really tell what's running.  Rather, it can just tell that stuff was printed to stdout.

Furthermore, lots of interactive processes just read stdin and print to stdout, such as a Python or Perl interpreter.  And for all of these, there are differences in how you should mark strings and escape characters inside them.

There is no way to get this perfect all the time.  It's a question of what behavior will annoy users the least.  Not quoting file names is certainly not the least annoying thing to do.

No there where two different colors. One for new output and one for 'there is an app running'.

That's probably just a color for yet another state of the terminal, probably the state that it's not running scroll-backed text, like in vim, less, mc, etc.  Donno what they call it, but it's just one of many states that a terminal emulator knows about.

Anyway, as was already said, there's no clean easy simple way to detect what is running in the terminal.  Yes, you can do a 'ps x' and filter for your pty and see what processes are connected to it...

no it is not. I am sure, because I requested that feature and discussed it with Cristiano De Michele (the mgt author). :)
With your doubket you are close to make me check the code

If you discussed it with him, why don't you give us some pointers :)

I've looked over mgt-cvs:

http://cvs.sourceforge.net/viewcvs.py/multignometerm/mgt2/src/enhanced_gui.c?view=markup

line 222:
void update_terms_state_in_tab(GtkWidget* tab, GtkWidget* focusterm)

seems to the function that sets the terminal-state. Still I'Ve not undrestodd hwo the code determines wheter an app is running (continuous data output? - but that would be a weak assumtion).

How about middle drag to add escape characters / quotes ?

You could even have a popup menu that would ask user to :
- Paste path "as is"
- Escape path
- Paste CD to directory, with escape characters
- Paste only the filename
- Cancel
- Set as terminal background image, if an image file

These are just examples of what could be in the menu, off the top of my head. Perhaps a menu is overkill, but a menu upon middle drag would be consistent with some Nautilus behavior.

Perhaps there are other more obvious and useful things that could be put in the menu ?

Love, Karderio.

Just noticed this is still a problem in Ubuntu Dapper.
How come we can't fix this? It's trivial, surely.

No it's not quite trivial; read the discussion.  However, we know what we want it to do now, and will accept a patch.

Behded, we discussed a number of possibilities in this bug report.  Could you recap which one would be the accepted behavior?  It seems you were preferring single quotes, since they're "stronger" in sh-compatible shells.  Escaping single quotes inside single-quoted strings is difficult in sh and csh.  You can't do it with a backslash.  You have the same problem in csh with double quotes, but sh only suffers this stupidity with single quotes.

For shells, the safest way to escape the quote character is to close your quote, open the other type of quote, put the quote character, close that quote, open your other quote back up.  If I single-quoted "What's up", I'd get 'What'"'"'s up'.  Of course, that's ugly as all sin, and is going to be garbage in anything that isn't a shell.

Lets go with double quotes.  It doesn't have the problem you are mentioning, and that it works as valid C and Python too.

So to clarify, for each file name, we quote the file name if it contains any of the following characters: any whitespace, ampersand, left or right paren, pipe, semicolon, single quote, left or right angle bracket.  The following characters should not cause quoting, and must be escaped with a backslash regardless of whether or not the file name is quoted: back tick, dollar sign, asterisk, question mark, backslash, double quote.  (They have to be escaped either way, so I don't see why they should cause quoting.)

This gives us perfect results for sh-compatible shells, near-perfect results for csh-compatible shells (only double quotes in file names will screw up csh), and no-worse-than-now results for most interactive scripting environments like Perl and Python.

I prefer we always quote if we are doing any editing.

Also, then only characters that need escaping in quotes are dollar sign, back tick, and double quote.

Oh, I see, shell globs aren't expanded inside quotes.  So always quote each file name with double quotes, and escape dollar sign, back tick, double quote, and (don't forget) backslash.  After four years and 48 comments of discussion to decide on the preferred implementation, that should be very easy code.  I'm setting the gnome-love keyword.

Created attachment 68870 [details] [review]
Always double quote if editing and escape '\', '$', '`', '"' 

Found this bug through the gnome-love bug search.

I'm attaching a patch which adds double quotes to file names and escapes chars if necessary.

Any comment will be appreciated. 
Thanks!

Umm, I think I prefer a patch using a GString and strpbrk.

*** Bug 349342 has been marked as a duplicate of this bug. ***

Bug 349342 had attachment 69923 [details] [review].

Patch in the dup is using g_shell_quote.  I'm going to commit that.

Using g_shell_quote unconditionally.  Enhancements should be filed against g_shell_quote.

2006-07-30  Behdad Esfahbod  <behdad@gnome.org>

        Bug 85926 – dnd'd filenames should be escaped
        Patch from Thomas Folz-Donahue

        * src/terminal-screen.c (drag_data_received): Quote filenames.