File history and/or "open" command converting \t to tab

[juha.vahokoski@…]

The following bug report has been submitted:
Platform:        Windows-7-6.1.7601-SP1
ChimeraX Version: 0.91 (2019-09-05)
Description
When I use a file history tab to open a previous file, the following occurs. For some reason a "t" and back slash are missing after "Models_maps", and the operation fails.

open "C:\\Users\\jva020\\OneDrive - University of Bergen\\XxxA-Cta1_paper\\Models_maps\test_proc\\job251\\symm_postprocess_masked.mrc"
File not found: C:\Users\jva020\OneDrive - University of Bergen\XxxA-Cta1_paper\Models_maps est_proc\job251\symm_postprocess_masked.mrc

OpenGL version: 3.3.0 NVIDIA 376.51
OpenGL renderer: Quadro K1200/PCIe/SSE2
OpenGL vendor: NVIDIA Corporation

[Tom Goddard]

The "\t" is an escape sequence for a tab character. Note that all the other backslashes in the path are "
" two backslashes except for the "\t".

How did you originally open this file before it was in file history? Did you use the Open / File dialog, or drag and drop, or did you type an open command on the ChimeraX command-line. It suspect that whatever means you used to open it originally did not handle the escape characters properly.

By the way, you are running Windows 7 which we do not support. Only support Windows 10. I have no Windows 7 machine to test on.

[Tom Goddard]

I made a file with a backslash in its name test\t123.cif and opened it by Open / File ..., drag and drop, and open command and it always produced a correctly escaped "test
t123.cif" in file history on macOS. I'm puzzled what might have put the "\t" tab character into the name. Will need to test on Windows 10.

[Tom Goddard]

If you just open the file with File / Open... does it make a correctly functioning File History thumbnail?

[Juha.Vahokoski@…]

Dear all,

This  phenomenon has been a persisting issue throughout a few different versions. I just have let it slip, and not reported it. Originally, I have opened the files using File/open dialog, and later tried opening using the file history tab.

Our university is on its way to transition all computers to Windows 10, but currently all my computers run on Windows 7. The deadline is by the end of this year.

Yesterday, I downloaded 0.91 for other reasons, and everything works like a charm. Apparently, this has changed between 0.90 and 0.91 (5-9-2019)

Regards,
Juha


-----Original Message-----
From: ChimeraX <ChimeraX-bugs-admin@cgl.ucsf.edu> 
Sent: Friday, September 06, 2019 8:26 AM
Cc: goddard@cgl.ucsf.edu; gregc@cgl.ucsf.edu; Juha Vahokoski <Juha.Vahokoski@uib.no>
Subject: Re: [ChimeraX] #2376: File history and/or "open" command converting \t to tab

#2376: File history and/or "open" command converting \t to tab
---------------------------------------+-------------------------
          Reporter:  juha.vahokoski@…  |      Owner:  Tom Goddard
              Type:  defect            |     Status:  assigned
          Priority:  normal            |  Milestone:
         Component:  Input/Output      |    Version:
        Resolution:                    |   Keywords:
        Blocked By:                    |   Blocking:
Notify when closed:                    |   Platform:  all
           Project:  ChimeraX          |
---------------------------------------+-------------------------

Comment (by Tom Goddard):

 If you just open the file with File / Open... does it make a correctly
 functioning File History thumbnail?

[Juha.Vahokoski@…]

Hi Tom.

I am seeing this again in 0.91. It comes and goes "randomly", i.e. it is depend how a file was open, and how one plan to use it. If I get a better sense of it, I will report back in more detailed manner.

Nevertheless, I noticed this, when launched through a cxc file:

Works:
movie encode "C:/Users/jva020/OneDrive - University of Bergen/XxxA-Cta1_paper/Figures/figs1_overall/test.mp4"
Movie saved to C:/Users/jva020/OneDrive - University of Bergen/XxxA-Cta1_paper/Figures/figs1_overall/test.mp4

Fails:
movie encode "C:\Users\jva020\OneDrive - University of Bergen\MyoA-Act1_paper\Figures\figs1_overall\test.mp4"

Duration: 00:00:03.40, start: 0.000000, bitrate: N/A 
Stream #0:0: Video: ppm, rgb24, 900x900, 25 fps, 25 tbr, 25 tbn, 25 tbc 
C:\Users\jva020\OneDrive - University of Bergen\MyoA-Act1_paper\Figures 
igs1_overall	est.mp4: Invalid argument

I usually copy long path names using file explorer or directly from a ChimeraX log. Forward and back slashes are different in these two...

-Juha
Comment (by Tom Goddard):

  If you just open the file with File / Open... does it make a correctly
  functioning File History thumbnail?

--
Ticket URL: <​https://plato.cgl.ucsf.edu/trac/ChimeraX/ticket/2376#comment:5>
ChimeraX <​http://www.rbvi.ucsf.edu/chimerax/>
ChimeraX Issue Tracker
}}}

[goddard@…]

Thanks for the extra info.  I will have to test on Windows.  On Mac a "\t" in the file name in movie encode is not interpreted as a tab character, simply puts a backslash and t in the file name.  So I'm not sure where "\t" is getting converted into a tab character.  I will have to test on Windows but I don't have access to a Windows machine today and am gone all next week.  I will look in a few weeks.

[Tom Goddard]

I tested on Windows. The trouble is that ChimeraX is currently interpreting \t in a typed commands as a tab character if the argument is surrounded by quotes, or if it is not surrounded by quotes it just leaves it as backslash t. So the following command fails

open "C:\Users\goddard\Desktop\tabtest\1hao3.cif"

but the unquoted version

open C:\Users\goddard\Desktop\tabtest\1hao3.cif

works. In the case you encountered there is a space in the path so quote marks were added to handle the space character, and that cause the \t to get turned into a tab when the command was interpreted.

It seems wrong \t should be treated one way when there are quotes and a different way when there are no quotes. We will need to figure out what the rules for backslash escapes are and fix the code.

[Tom Goddard]

Greg, Eric and I discussed it and decided that command file name arguments should not interpret backslashes as escape sequences (with or without quote marks). But string arguments (StringArg) should interpret backslash escapes (with or without quotes). Greg will make that change.

I have changed file history to quote using a new quote_path_if_necessary() routine that currently adds quote marks and escapes backslashes so that the bug reported here is fixed. When Greg changes interpretation of file arguments that routine will need to change to not escape backslashes -- just adding surrounding quote marks.

[Greg Couch]

Fixed. Working on more general solution. Each *Arg class will provide an unparse method that will generate a string from a value that, when parsed, will regenerate the value for that argument type. So quote_path_if_necessary will be FileNameArg.unparse and quote_if_necessary will become StringArg.unparse. Other unparse methods will be added as needed.