CmdPi repete a sabedoria recebida de que os interpretadores de comandos da Microsoft funcionam como shells do UNIX. Foi assim que todos votaram com os pés na década de 1980. Mas na verdade eles não fizeram e ainda não o fazem.
Os nomes dos comandos podem e podem ser separados do comando tails por um bom número de caracteres, não apenas por espaço em branco. Pode-se usar o caractere de igualdade, por exemplo, ou a vírgula. path=C:\DOS é um comando e uma cauda. Assim também é dir,dos . Mais notoriamente, pode-se usar o ponto final. Daí o bem conhecido truque echo. para ecoar uma linha em branco em um script de comando. O que é menos conhecido é que echo; , echo+ , echo= , echo( , echo, , echo[ , echo] , echo\ e echo/ farão o mesmo (embora nem sempre para alguns deles).
Na verdade, há uma chamada da API do DOS ( int 21h,ax=6505h ) que pode ser usada para obter a lista completa de caracteres que são chamados de "caracteres de terminação de nome de arquivo". E os interpretadores de comandos do DOS usam-no para determinar quais caracteres terminam um nome de comando e iniciam a cauda do comando. (Interpretadores de comando da Microsoft para sistemas operacionais não-DOS provavelmente apenas hardwire o conjunto de caracteres.)
A barra invertida é um desses caracteres e, em intérpretes de comando do command da Microsoft no MS-DOS para cmd da Microsoft no Windows NT (incluindo% / cmd da IBM para OS / 2 ao longo do caminho) execute cd\ e o resultado será que o interpretador de comandos altera o diretório para \ . Se o caractere de terminação está incluído na cauda do comando, na verdade varia de comando para comando. Com o comando cd , é. Com os comandos dir e path , não é. (Sim, o analisador de linha de comando nos interpretadores de comandos da Microsoft se comporta de maneira diferente de acordo com o comando interno a ser executado.)
Isso nunca foi documentado, no entanto. Como eu disse: a maioria das pessoas votou com os pés na década de 1980 para abraçar o paradigma shell UNIX, embora coisas como análise de argumentos e citações sejam uma vasta ficção conspiratória implementada não pelo interpretador de comandos, mas pelas bibliotecas de tempo de execução de várias linguagens de programação. implementações para DOS; e você verá que a maior parte da literatura afirma com confiança que o espaço em branco separa o nome da cauda, mesmo que não seja verdade. echo. é geralmente descrito como um capricho e um truque, e muito raramente descrito como simplesmente um caso de uma sintaxe geral que os interpretadores de comandos da Microsoft empregaram por quase três décadas.
Eu recomendo seguir a tendência dos anos 80 aqui, e não confiar nessa sintaxe pouco conhecida. Use espaço em branco. É o que as pessoas documentam. É o que os gostos da IBM e da própria Microsoft documentam. É o que a sabedoria popular afirma ser o caso. É o que os chefes do UNIX esperam. ☺
Meu interpretador de comandos foi com os gráficos e descrições de sintaxe que estão no IBM doco. No entanto, você descobrirá que o FreeCOM implementa esse comportamento pouco documentado, assim como os interpretadores de comandos da JP Software e o command do OpenDOS. O doco da JP Software recomenda o uso de espaço e descreve o uso de outros caracteres de terminação como "ilegal". É, no entanto, um dos poucos lugares que realmente afirma na documentação oficial que há uma alternativa a ser obtida.
Leitura adicional
- Jonathan de Boyne Pollard (2010). Diferenças de outros intérpretes de comandos . Guia do usuário do interpretador de comandos de 32 bits.
- "Nomes e parâmetros de comando" . TCC / Take Command Help. Software JP.
- 'lib / is_fnamec.c' . FreeCOM Source. SourceForge.
- 'shell / command.c' . FreeCOM Source. SourceForge.