DosTips.com

The excerpt from `CMD /?` output (concerning file completion I suppose):

The special characters that require quotes are:
<space>
&()[]{}^=;!'+,`~

Rectangular brackets are used in `FINDSTR` regex expressions and in `.REG` files to identify registry nodes , while curly brackets are used in CLISD keys ,but I'm not sure if this is the reason as the cmd.exe does not use these directly . Is this a relict from dos times? Not sure also why '+ and ` are here ...

The + is used in the COPY command.
Back quote is used in the FOR command.

Squashman wrote:Back quote is used in the FOR command.

also the single quote...
But why these warnings are not in the corresponding commands help messages?

And [] and {} are most annoying - where I can go wrong using these symbols if I'm working with files? I think even with FINDSTR and [] is not so easy.

with {} may be I can confuse explorer.exe if it's called from command line?

npocmaka_ wrote:The special characters that require quotes are:
<space>
&()[]{}^=;!'+,`~

These are only the special characters of the file and directory completion (FDC) and not of any other command:
and then use Ctrl+F => fail (the same with the other FDC special characters, tested under win xp home).

It isn't explained why it fails, only that it fails ... (treated as special characters and not as part of a filename),
so you have to guess if you want to know why these characters are treated as special characters.

One possibility may be (as it seems, you have guessed), that the FDC don't want to affect other (?internal?) commands (?all listed in help?), working with files:
- std cmd flow may use "&()" and <SPACE> (but why is the "|" not treated as a special character)
- delayed expansion "!"
- "ftype" may need "="
- the "for /F" command uses "'`,;"
- "copy" uses "+"
- using pathes with a special CLSID may need "{}"
- still unclear characters in front of a file/path name: "[]^~"

But it may also be, that these characters are only internally used for encapsulating a search tree into a single string of a recursive function;
some special characters needed to realize links to other subtrees, or
to realize grouping of nodes, or
to realize a suffix tree of the (actual) search string, or
... .
So you may affect this function by creating a string with the correct syntax;
if this were the case this syntax is not published and it is nearly impossible to derive it.

It also may be, that both possibilities are in use; or something different.

penpen

npocmaka_ wrote:The excerpt from `CMD /?` output (concerning file completion I suppose)

In the context, it seems to refer to file completion, only.

Don't think it's about internal commands - otherwise many more characters would be in the list such as "-" (set/a), "$" (prompt) etc. I don't think it's about file/directory names either - for example "md something.{20d04fe0-3aea-1069-a2d8-08002b30309d} & start "" something.{20d04fe0-3aea-1069-a2d8-08002b30309d}" opens explorer on "my computer" without requiring quotes (and the .{CLSID} directory extension handling is an explorer "shell extension" trick, anyway, which doesn't apply at the cmd prompt).

That said, some of those characters are "special" in their own ways, for example "echo?" emits a blank line for ?=[]+ (unless a namesake file exists on disk - http://www.dostips.com/forum/viewtopic.php?p=4554#p4554).

Liviu

this works with _ + ctrl+f
- [],+= are replaced with _ in short file names.Probably that's why ~ is also a special symbol here.And I think this is the part of the answer (despite short names can be turned off?)

But what is ; is doing here as it cannot be part of file name?

Also a little bit reminds me that :
viewtopic.php?f=3&t=5057

npocmaka_ wrote:But what is ; is doing here as it cannot be part of file name?

It can be in a filename and foldername.

I never change eol= but file processing would fail with ; at the start,
and a folder on the path with ; in the name would cause havoc.

foxidrive wrote:

npocmaka_ wrote:But what is ; is doing here as it cannot be part of file name?

It can be in a filename and foldername.

I never change eol= but file processing would fail with ; at the start,
and a folder on the path with ; in the name would cause havoc.

My mistake - of course it can be part of file name.Also changed to underscore in short file name.

I'm not sure, if i've described well, what i meant above, so i try it with examples.
Assumed the possibility is true, that the file and directory completion FDC don't want to affect other commands, when working with files.

The character "-" is never followed by a file in any of the listed commands (if i've not overseen one), so this character can be ignored by the FDC (=> no special character for the FDC).

Here is a command line example for ";":
Using Ctrl+F here doesn't remove the prior, so the for command is not affected and you may build easily the file list.
This is also an example for "(",<space>, ",": just leave all after that charcter.

The other for examples:
to select an executable to generate the output.
This also works for Ctrl+D; just add an "\" after the selected directory, and the next file/directory completion works within the selected subdirectory.

penpen

Liviu wrote:That said, some of those characters are "special" in their own ways, for example "echo?" emits a blank line for ?=[]+

I've tested this behavior for all that special characters under all my old MS-DOS versions (using QEMU):
My 3.30 disk was damaged, so it could be that those results are wrong.
("echo?" always results in "Bad command or file name")

Nevertheless it seems, that the special handling of "[]+" (";,") is a build in relict.

penpen

Edit: Removed verified wrong information about using of [].

btw. The documentation of LABEL on technet:
http://technet.microsoft.com/en-us/libr ... 90925.aspx

Limitations on volume label names

A volume label can contain as many as 32 characters for NTFS volumes and as many as 11 characters for FAT volumes and can include spaces but no tabs.

FAT volume labels cannot contain any of the following characters:

* ? / \ | . , ; : + = [ ] < > "

This limitation does not apply to NTFS volumes.

I have found out why [] are special characters:
MSDOS 2.0 uses ANSI escape sequences for internal "signaling" (rudimentary from todays view) and so the parser needed to process them.
For example the command "cls" sends ESC"[2J" as the signal for "ANSI Clear screen" or "Erase Display".
You may get a full list of such escape sequences used by MDDOS 2.0 in the source text file "ANSI.txt".

See http://www.dostips.com/forum/viewtopic.php?p=33989#p33989:
-> link in that topic to "The Official Microsoft Blog"
-> link "public" (below the picture)
-> link "microsoft-ms-dos-early-source-code"
-> download link: "Microsoft DOS V1.1 and V2.0 Source Code"

penpen

Edit: Added the "-> download link: ..." part.