An alternative command prompt (Dos9)

[Darkbatcher]

Hello guys !

I woulld like to present a free (as in "freedom" ) cmd-like command prompt called Dos9 to you. I've been programming this for some time now, and I think is now mature enough to be released more publicly. It not big enough to replace cmd.exe completly (though it has been a goal from the begining), but I hope it can grow.

I have been using batch on windows for years, and despite the fact that batch is really powerfull, it as several inconsistencies due to its syntax (and the way it is actually parsed). It also appeared it was bound to dissapear because of the lack of newer features that it need (like command substitution, for example "$(command)"), and it would be sad if it does. So that I decided to create my own command prompt in order to make working things that I wanted to work.

It now supports a large part of cmd.exe features, like common commands, block-level redirection, redirections, pipes, expansion FOR and IF command.

If you're interrested, you can take a look at http://sourceforge.net/projects/dos9/ to learn more or download source code or binaries.

Fell free to contribute, submit any suggestion, code, fixs or whatever. I would also like to recieve comments and what you think about it

@+

[aGerman]

Nice work

Normally we discuss about Windows Batch related stuff here (command.com, cmd.exe). Your topic does more tend to C in my opinion.
However I just tried to get the help documentation to see what commands are actually supported. But ...

DOS9 D:\dos9-2014.0.9b-w32>hlp
Error : Unable to find folder "D:\dos9-2014.0.9b-w32/share/doc/ansi".
Error : Unable to acces to file "commands.ansi".

DOS9 D:\dos9-2014.0.9b-w32>dir share

Last change Size Attr. Name

20/04/2014 17:29 D share/.
20/04/2014 17:29 D share/..
20/04/2014 17:29 D share/locale
20/04/2014 17:29 D share/man
0 Files
4 Folders

DOS9 D:\dos9-2014.0.9b-w32>

Unforunately the doc folder is completely missing in your SourceForge download.

Regards
aGerman

[Darkbatcher]

Sorry, I did not included the documentation. Anyway, you can generate it through the following command :

Code: Select all

hlp /b en_US CP850

you may need to replace CP850 by another code pages (you console's codepage) in order to translate non-ascii characters into something printable in your console. Then you should be able to browse the documentation through "hlp command". or see the 'share/doc/html/directory' for html help.

You're right this coded in C, even if both 'hlp' and 'Dos9_Auto' are actually batch scripts. But however, I think posting in a C forum would not be of any help, because most of users will never submit a fix, or a patch, but most of them will test batch scripts, and possibly encounter bugs and report them. This kind of feedback is usefull for developers I think.

Thanks for feedback
Regards

[aGerman]

Thanks works now.

I think posting in a C forum would not be of any help, because most of users will never submit a fix, or a patch, but most of them will test batch scripts, and possibly encounter bugs and report them.

I agree. You would need the support of people who frequently use Batch scripting to improve your interpreter.

Regards
aGerman

EDIT I was curious about commands that I never saw before but ...

DOS9 D:\dos9-2014.0.9b-w32>agraf /?
Error : "agraf" is not recognized as an internal or external command, an operable program or a batch file.

DOS9 D:\dos9-2014.0.9b-w32>batbox /?
Error : "batbox" is not recognized as an internal or external command, an operable program or a batch file.

DOS9 D:\dos9-2014.0.9b-w32>bg /?
Error : "bg" is not recognized as an internal or external command, an operable program or a batch file.

[Darkbatcher]

Oh dear !

Agraf is a command that i created a long time ago, but i didn't managed to include it in the pakage (because it is to be replaced by Dos9 internals, I hope).

If you wanna see it capabilities you can go there http://batch.xoo.it/t2877-BETA-Commande ... htm#p21978 , you can get the binary here, and there's a few example, but i don't know if I will be able to retrieve source code

However, I abborted devellopement of the program because it was typically to hard use for average and advanced batch programmer (it required using new concept, and a new batch-like programming systems), and it was only able to make simple GUIs.

For batbox, it's another command of me, you can get info there batch.xoo.it/t2243-Commande-Externe-Batbox-v1-0.htm , it a really small command written in ASM, which is a kind of swiss army knife for console graphics. it as a really little size, in order to be able to be self-generated from batch scripts. To keep it small, it doesn't include help, it's provided as external files. If you browse the category "Programmation Jeux en Batch" of the forum, you shoud find a bunch of games using it, like there batch.xoo.it/t2583-Snake-Game.htm?q=snake#p20156 ( just copy source code)

For bg, its a command from carlos, a guy from chile, you can find it there http://batch.xoo.it/t2238-BG-exe-Utilit ... -Games.htm

Most of links are in french, as they are in a french forum for batch

@+

[aGerman]

OK, it doesn't matter.

I did some random tests and I found at least one thing that needs to be revised. Please have a look at expressions that where quoted. E.g.

Code: Select all

set "var=a&b"
for %%i in (1,2;3="4 a") do echo %%i

Furthermore CMD recognizes oct and hex values in FOR /L loops

Code: Select all

for /l %%i in (1,1,0xA) do echo %%i

FOR /F loops

Code: Select all

for /f "skip=0x1" %%i in (test.txt) do echo %%i

IF statements with literal operators (EQU, LSS, GTR etc.)

Code: Select all

if 10 equ 0xA echo OK

CMD does recognize separators like spaces, tabs, semicolons and equal signs besides commas in FOR /L Loops

Code: Select all

for /l %%i in (1 1 10) do echo %%i

CMD removes spaces that appear in SET /A statements in front of the equal sign.

Code: Select all

set /a x = 1 + 2

DOS9 generates a variable %x % where CMD generates %x%.

Regards
aGerman

[Darkbatcher]

I did some random tests and I found at least one thing that needs to be revised. Please have a look at expressions that where quoted. E.g.

Code: Select all

set "var=a&b"
for %%i in (1,2;3="4 a") do echo %%i

Ok, I knew about the first problem. But anyway, using quotes on set is pain in the ass because it leads to ambigous situations where determining where to cut parameters is really anoying.

Relating to the "&" that is actually interpreted, hum well, I've seen it for some time now, but I decided no to fix it, because it is really arsh to make it work this way and well, i can't see why should quotes have precedence over operators like '&'. To be honnest, I do not even know why and how guys from microsoft managed to do this.

For the second quote issue, I decided a way to handle it, because i had no idea how quotes are really handled. That's a problem because use of quotes is typically ambiguous that is, its hard to figure out how to split tokens for some cases, for example:

Code: Select all

foo "some args"foo foobar"

you can either choose to see only one or two distinct arguments. So I would like some enlightments about how this is supposed to be handled...

For others, this is quite easy to fix. I did not implemented this because I was simply not aware of that, its never mentionned in documentations.

Thanks

[aGerman]

The right handling of quoted expressions is important for the compatibility with conventional Batch scripts. You will rarely see an unquoted SET assignment here at DosTips because it wouldn't be safe enough in most cases (as my ampersand example demonstrates). Of course you have to do a lot of tests and eventually various commands behave differently with unpaired quotation marks.
If you realy want to develop a compatible interpreter the command line parsing must be the same as for cmd.exe. I strongly recomment you to read How does the Windows Command Interpreter (CMD.EXE) parse scripts?. jeb and dbenham did loads of tests to figure out what happens behind the scenes.

Regards
aGerman

[Squashman]

For bg, its a command from carlos, a guy from chile, you can find it there

You mean this guy.

[Darkbatcher]

The right handling of quoted expressions is important for the compatibility with conventional Batch scripts. You will rarely see an unquoted SET assignment here at DosTips because it wouldn't be safe enough in most cases (as my ampersand example demonstrates). Of course you have to do a lot of tests and eventually various commands behave differently with unpaired quotation marks.
If you realy want to develop a compatible interpreter the command line parsing must be the same as for cmd.exe. I strongly recomment you to read How does the Windows Command Interpreter (CMD.EXE) parse scripts?. jeb and dbenham did loads of tests to figure out what happens behind the scenes.

Ok ! You're right... I reflected and it appears to me that using quotes should silence the special characters like &.

Of course, I'll investigate further on the way quotes are paired... But I'm not to reproduce somewhat stupid however. For instance the author on the page you've given (thank you so much for it) says that if no "!" are found during delayed expansion, then carrets (^) are not removed. This is absolutely stupid, who needs (or uses) such kind of behaviour ? Why did cmd devs do that ? Was their source code not long enough ? or was it simply to simple to understand ? Well, I'm making fun of them, but If anybody knows the advantage of this, i'd like them to shed some light on this.

Anyway, the post is really interresting... The way I parse scripts is a little bit different, but it is mostly the same. I think I dont need to follow any cmd.exe behaviour, because the goal is not to get something fully compatible with cmd.exe (why no use cmd.exe for that purpose ? ). The goal is to provide a interpretor that is mostly compatible (I mean you can most batch files without modification) and to fix deficiences of cmd.exe.

Of course, I will be quite long to address the problem of quotation mark now because i'm very busy, and there's a lot of work to be done.

And, there is anyway other guys than "this guy" in chile Or at least, that's what I've been told

Regards
DarkBatcher

[Liviu]

It also appeared it was bound to dissapear because of the lack of newer features that it need (like command substitution, for example "$(command)"), and it would be sad if it does.

Doesn't appear to me that cmd is bound to disappear. If anything, it's still being worked on, bugfixed and even improved on in latter Windows.

I think I dont need to follow any cmd.exe behaviour, because the goal is not to get something fully compatible with cmd.exe (why no use cmd.exe for that purpose ? ). The goal is to provide a interpretor that is mostly compatible (I mean you can most batch files without modification) and to fix deficiences of cmd.exe.

Define "mostly" If your goal is to practice C while writing a cmd-like interpreter, then hat's off - you've set yourself a pretty high bar. If, however, you mean for dos9 to be taken even remotely seriously as a drop-in alternative to 'cmd' then it's a different game altogether. You'd need to spell out every limitation and every departure from cmd syntax or behavior. There is tons of batch code out there, working and verified to work under 'cmd', much of it in sensitive areas like file/network/administration. Not everybody is going to be as enthusiastic to spend the time and retest/revalidate under a new shell.

Now, for nitpicks... Dos9 doesn't seem to like "X:" to change the current drive (Error : "x:" is not recognized as an internal or external command, an operable program or a batch file.). That's somewhat of a turnoff when it's the very first command one tries at the new prompt. But then I found that "CD /D X:\" worked, which was good. But then again, I found that "CD X:\" alone also worked, without "/D", which is bad. If the current drive is not X: then "CD X:\" is supposed to set the current directory on drive X: to its root X:\, and "CD X:" (without the backslash) is supposed to display the current directory on drive X: - neither should actually change the current directory to X: unless "/D" is specified. That behavior hasn't changed since ancient DOS.

One other thing, the error reporting needs to be improved. It looks like the input/output is done in a "narrow" codepage, not Unicode, and - worse - errors are silently ignored.

Code: Select all

DOS9 c:\temp>md ‹αß©∂€›

DOS9 c:\temp>dir /ad

Last change             Size    Attr.   Name

21/04/2014 20:16                D       .
01/01/1980 00:00                D  HS   ..

DOS9 c:\temp>cmd /c md ‹αß©∂€›
The syntax of the command is incorrect.

Liviu

[Darkbatcher]

It also appeared it was bound to dissapear because of the lack of newer features that it need (like command substitution, for example "$(command)"), and it would be sad if it does.

Doesn't appear to me that cmd is bound to disappear. If anything, it's still being worked on, bugfixed and even improved on in latter Windows.

Seriously ? what is powershell made for ? Maybe I'm wrong but microsoft has designed it as a replacement for cmd. However, I'm sure people here don't like powershell ... it has its deficiencies, too.

Define "mostly" If your goal is to practice C while writing a cmd-like interpreter, then hat's off - you've set yourself a pretty high bar. If, however, you mean for dos9 to be taken even remotely seriously as a drop-in alternative to 'cmd' then it's a different game altogether. You'd need to spell out every limitation and every departure from cmd syntax or behavior. There is tons of batch code out there, working and verified to work under 'cmd', much of it in sensitive areas like file/network/administration. Not everybody is going to be as enthusiastic to spend the time and retest/revalidate under a new shell.

My goal is effectively to have good time practicing C while coding a cmd-like shell. But if i can actually turn it into a serious alternative, why not ? And when I say "mostly", I mean "Ok guys, let's implement any known and usefull behaviour, but don't care of making cmd hacks actually functionnal". Obviously it's not ready, that's why I post here (maybe the title is misleading, but I can ensure you that it is anything but advertisment)

Now, for nitpicks... Dos9 doesn't seem to like "X:" to change the current drive (Error : "x:" is not recognized as an internal or external command, an operable program or a batch file.). That's somewhat of a turnoff when it's the very first command one tries at the new prompt. But then I found that "CD /D X:\" worked, which was good. But then again, I found that "CD X:\" alone also worked, without "/D", which is bad. If the current drive is not X: then "CD X:\" is supposed to set the current directory on drive X: to its root X:\, and "CD X:" (without the backslash) is supposed to display the current directory on drive X: - neither should actually change the current directory to X: unless "/D" is specified. That behavior hasn't changed since ancient DOS.

Is this really bad that "/D" does not work ? In fact, it is ignored. I guess this is a matter of security, but I can't see the point of this.
For the "x:" syntax, it do not use it, and I did not think it was so widely used. "CD X:", I did not even know about that. That's what's wonderfull with cmd, every new post teach me a brand new syntax

One other thing, the error reporting needs to be improved. It looks like the input/output is done in a "narrow" codepage, not Unicode, and - worse - errors are silently ignored.

Code: Select all

DOS9 c:\temp>md ‹αß©∂€›

DOS9 c:\temp>dir /ad

Last change             Size    Attr.   Name

21/04/2014 20:16                D       .
01/01/1980 00:00                D  HS   ..

DOS9 c:\temp>cmd /c md ‹αß©∂€›
The syntax of the command is incorrect.

Ok, that's indeed an issue... AFAIK, I had the same problem (which should still exist) that I can effectively cd to some non-existing directory without an error to printed because the CRT function did not returned on error... I think it was a bad idea to use these function. For handling wide characters, you know, tough cookies I not used wide characters because it is a mess on windows, but i can be fixed... to be curious, which unicode page are you using ? utf-8 or utf-16 ?

Thank you for feedback

[penpen]

Seriously ? what is powershell made for ? Maybe I'm wrong but microsoft has designed it as a replacement for cmd.

It is true that cmd.exe, the complete WSH (cscript/wscript with JScript, and VBScript), the complete .NET, and some other tools should be replaced by Powershell (->Monad):

1. A programmatic shell (e.g. sh, csh, ksh, bash)
2. A set of administrative commands (e.g. ifconfig, ps, chmod, kill)
3. A set of text manipulation utilities (e.g. awk, grep, sed).
4. Administrative GUIs layered on top of commands and utilities

But in short Powershell was designed to support system developers, testers, power users, and administrators only.
A subset of the Powershell commands may be free to use (if not disabled by admin)
and should replace these; see:
http://blogs.msdn.com/cfs-file.ashx/__key/CommunityServer-Components-PostAttachments/00-01-91-05-67/Monad-Manifesto-_2D00_-Public.doc.
Note: Monad is something like the powershell roadmap, so if all is implemented Powershell == Monad (actually not).

Is this really bad that "/D" does not work ? In fact, it is ignored.

I haven't tested it, but it sounds, like DOS9-"cd" implementation always does what cmd-"cd /D" does.
That may be a problem for all scripts setting up directories in different volumes:

Code: Select all

:: actual directory is P:\printerList\CIP_Pool_3
cd E:\errors\printerList\CIP_Pool_3
cd W:\warnings\printerList\CIP_Pool_3

:: DOS9 actual directory: W:\warnings\printerList\CIP_Pool_3
:: cmd.exe actual directory: P:\printerList\CIP_Pool_3
for /F "tokens=* delims=" %a in (printer.txt) do (
:: (...)

This is easy to patch, but you have to review all scripts.

For the "x:" syntax, it do not use it, and I did not think it was so widely used.

I've seen tons of scripts using that.
Most of them some time ago, but in one of the last topics it was used:
http://www.dostips.com/forum/viewtopic.php?f=3&t=5531.

"CD X:", I did not even know about that. That's what's wonderfull with cmd, every new post teach me a brand new syntax

Actually i haven't tested it, but this leads me to the question:
Are the dynamic environment variables implemented (at least the documented ones are used intensively)?
Documented ones:
"CD", "DATE", "TIME", "RANDOM", "ERRORLEVEL", "CMDEXTVERSION", "CMDCMDLINE".

Undocumented ones:
- if volumes exist and are accessed/ cd used on that drive: "=C:", "=C:"
- If an exitcode was set: "=ExitCode"

penpen

[Darkbatcher]

I haven't tested it, but it sounds, like DOS9-"cd" implementation always does what cmd-"cd /D" does.
That may be a problem for all scripts setting up directories in different volume:

Ok ! it would indeed be a great advantage to have such different paths on different paths, this needs to be implemented !

Are the dynamic environment variables implemented (at least the documented ones are used intensively)?
Documented ones:
"CD", "DATE", "TIME", "RANDOM", "ERRORLEVEL", "CMDEXTVERSION", "CMDCMDLINE".

They're all implemented execpt %CMDEXTVERSION% and %CMDCMDLINE%. I don't know if it is bad, but %CD% is implemented as a real variable which is set by CD and at startup.

Undocumented ones:
- if volumes exist and are accessed/ cd used on that drive: "=C:", "=C:"

am I to understand that %=C:% expands to the current directory on the c: drive ? That would be intersting.

[penpen]

am I to understand that %=C:% expands to the current directory on the c: drive ? That would be intersting.

Yes, but it only contains a non empty value, if the volume was referenced eralier:
Example volume "X":

Code: Select all

C:\>echo %=X:%
%=X:%

C:\>cd X:\Temp

C:\>echo %=X:%
X:\Temp

C:\>

penpen