Special characters in quoted strings are not handled as strings

[Lewis Rosenthal]

Nifty summary, huh?

Normally, the presence of a semicolon indicates an include list. To override that functionality, it is suggested to surround the semicolon by square brackets. However, this is not only unintuitive, but often impossible (such as when filenames captured in a wildcard specification include semicolons and these characters are not specified on the command line).

Use case:

[c:\usr\lib] del "urpo.dll;123456"
There are no more files. "C:\var\temp\usr\lib\urpo.dll"
There are no more files. "C:\var\temp\usr\lib\123456"
     0 files deleted

In the above example, tab completion was used to specify the file. The inconsistency (see related ticket #18) becomes more confusing with behavior such as:

{0}[c:\var\temp\usr\lib] copy \usr\lib\urpo.dll *[;]123456
C:\usr\lib\urpo.dll => C:\var\temp\usr\lib\urpo.dll[;]123456
     1 file copied

which actually creates the file with the square brackets surrounding the semicolon, whereas:

{0}[c:\var\temp\usr\lib] copy \usr\lib\urpo.dll "*;123456"
C:\usr\lib\urpo.dll => C:\var\temp\usr\lib\urpo.dll;123456
     1 file copied

seems to work.

Thus knowing when to quote, when to use square brackets, and when to use both (apparently) is highly dependent upon the command being issued and the circumstances surrounding the occurrence(s) of the special character(s).

[Steven Levine]

I agree that this is cumbersome. Having double quotes turn off the specialness of the semicolon seems like a solution, but it has its own set of issues. I can envision arcane cases where the names in the include list contains whitespace that needs to be quoted.

FWIW back quotes will turn off the specialness of the semicolon, but this solution can not be used in all cases.

One possible solution would be a SETDOS option to turn off the include list feature. Another is make the include list separator configurable.

A non-4OS2 solution would be to have urpo, use a different separator character. The semicolon is a problem for *ix shells too.

[Lewis Rosenthal]

I happen to like your idea of making the separator user-configurable. Normally, this would be set in startup, but could be overridden on the command line (e.g., SET SEPSTR=) before issuing the desired command.

[Lewis Rosenthal]

I thought I'd appended this somewhere, but a more frequent annoyance caused by this is when attempting to CD to:

\blah\blah\chatzilla\logs\something%3a1234

The "%" requires a double "%" (no quotes around the string required, but a simple tab completion won't work, and neither would a backslash - obviously - nor square brackets).

[StevenHL]

FTR, tab completion should work. The problem will be that as you noticed double quotes alone don't preserve the % character. Backquotes will preserve the % character, but will break tab completion.

My current workaround for this is to follow the backquote with a space and clean up after doing the tab completion. I will type

` \blah

and do the tab completion and add the trailing backquote. Sometimes you can leave the space following the leading backquote and everything will work as desired. At the worst, you will need to Ctrl-Left and delete the space before pressing Enter.

[Steven Levine]

Ticket retargeted after milestone closed