VOGONS


4DOS Color Prompt?

Topic actions

First post, by Dacobi

User metadata
Rank Newbie
Rank
Newbie

I remember back in the day, people where making interactive prompts with all sorts of info, color and even char animation.

Does anyone have any examples of this?
Preferably for 4DOS

[Edit] For instance, is it possible to execute an arbitrary commend within the prompt?

/Jacob

Reply 1 of 22, by Dacobi

User metadata
Rank Newbie
Rank
Newbie

I found this example in the manual:

prompt $e[s$e[l;lf$e[41;l;37m$e[K[$z] $<S Time: $t$h$h$h Path: $p$e[u$e[0;32m$n$g

It works after adding ansi.sys and increasing the environment size.

It's a good example of what I'm trying to do,
but I still don't understand how it would be possible to add real-time char animations?

Reply 2 of 22, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie
Dacobi wrote:

add real-time char animations?

to the prompt? you cant. you can change colours as you quoted, with ansi commands. thats as good as it gets.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 4 of 22, by aleksej

User metadata
Rank Member
Rank
Member

I think putting 4CLOCK.COM in bottom-left edge and shifting PROMPT string slightly to the right can do trick. But only current PROMPT would be animated by this way. In all prior upper PROMPTs you will see timestamps, not real time clock.

Sorry, reading your "real-time char animation", like a real-time clock animation. 😵
Don't know how do that.

In my PROMPT string, also 4DOS powered, i indicate choosed config (aka MENUITEM) by specific color set (this can be done with regular command.com too, only ANSI driver needed) and put DOSSHELL level and free conventional mem (4DOS only).
66.jpg

Reply 8 of 22, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie

COMMAND.COM cannot do this without ANSI.SYS loaded. 4DOS does this, but thats not COMMAND.COM.... however

@echo off
echo <ESC>[0;0H\
timeout 1
echo <ESC>[0;0H^|
timeout 1
echo <ESC>[0;0H/
timeout 1
echo <ESC>[0;0H-
timeout 1

Works in Windows 10 (which has ANSI support out of the box), you will need to use different escape for the '|' pipe char (i.e not ^|) for older dos.

replace "<ESC>" with the ASCII escape char (27). This outputs the chars to the same location ~1 sec apart giving the impression of a spinning pipe.

More info: https://www.computerhope.com/ansisys.htm

Reply 9 of 22, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

ah yes, of course you can just echo escape codes. I guess I misunderstood Dacobi wanted it in his prompt so it would animate while just waiting for input or something.

--/\-[ Stu : Bloody Cactus :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 12 of 22, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie

Ah ok, dunno how I missed that nugget... it's even in the title 😵. I thought OP might want it for a script.

In which case, yes I can only echo (pun intended) others when saying I'm pretty sure this isn't possible. Afaik... the prompt command has no mechanism to 'animate'. nix escape codes can give you blinking colours, but no animations. Animation requires a concept of timing and there is no way to apply this via the prompt command in MSDOS. Stuff like ANSI and ncurses can do this, but not natively in DOS... i.e it would be used by a 'shell' program perhaps to emulate the look and use of a command prompt.

As for what your friend may have had... maybe a TSR which can be used to callback and change the prompt silently? ... I don't even know if this is possible?

Alternatively, there were various CLI programs and DOS alternatives (like 4DOS) which can act as a shell over stdin, stdout etc and simply pipe to stdout or invoke dos commands. Perhaps one of these was used as that could present a prompt numerous different ways. Sounds like a straight forward qbasic program 😀

Dacobi wrote:
How do I create this char in edit? […]
Show full quote
spiroyster wrote:

replace "<ESC>" with the ASCII escape char (27)

How do I create this char in edit?

If I type echo ^[[0;0h\ I get an error
"Invalid path"

Invalid path sounds like you are running it as a batch script? Short answer is I don't know, I would have suggested what you wrote, but the ^ escape is later DOS I think? I don't have access to an old DOS environment atm so can't check myself. As described above though, this cannot be done via a script (which calls prompt command)... it would have to be a program, in which case '\033' would be used in C syntax.

Reply 13 of 22, by Dacobi

User metadata
Rank Newbie
Rank
Newbie
spiroyster wrote:

As for what your friend may have had... maybe a TSR which can be used to callback and change the prompt silently? ... I don't even know if this is possible?

I was thinking something similar.

One thing to note, the prompt I'm referring to wasnt a simple "prompt" command.
It was a larger bat file with IF statements and the like.

Reply 14 of 22, by Dacobi

User metadata
Rank Newbie
Rank
Newbie
spiroyster wrote:

Alternatively, there were various CLI programs and DOS alternatives (like 4DOS) which can act as a shell over stdin, stdout etc and simply pipe to stdout or invoke dos commands. Perhaps one of these was used as that could present a prompt numerous different ways. Sounds like a straight forward qbasic program 😀

I don't follow.
I'm allready using 4DOS, but how would I "present a prompt numerous different ways"?

Reply 15 of 22, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie
Dacobi wrote:
spiroyster wrote:

Alternatively, there were various CLI programs and DOS alternatives (like 4DOS) which can act as a shell over stdin, stdout etc and simply pipe to stdout or invoke dos commands. Perhaps one of these was used as that could present a prompt numerous different ways. Sounds like a straight forward qbasic program 😀

I don't follow.
I'm allready using 4DOS, but how would I "present a prompt numerous different ways"?

Sorry, wasn't talkig about 4DOS specifically, other CLI shell programs which either sit ontop of DOS (as a layer), or provide their own CLI. The prompt limitations in MSDOS are a result of the arguments that the "prompt" command supports, and I suspect the same would be for 4DOS's equivalent. Your friend may have used one of the many other CLI/shell programs which may or may not be restricted to presenting the prompt to $p$g or equivalent. These other shell programs may support "animation" of some kind?

iirc there were quite a few of these programs that went around, and also back int day I think it was quite popular with budding programmers to write something which does this as an academic exercise. It is actually quite straight forward to write since all the needs to be done is to hook into stdout/stderr to display the console output in your program, and strings (user input) simply sent to stdin. Think of it like 'skinning' the console.

Reply 16 of 22, by Dacobi

User metadata
Rank Newbie
Rank
Newbie
spiroyster wrote:

Think of it like 'skinning' the console.

Wouldn't this replace 4DOS or COMMAND.COM?

My memory may be playing tricks on me, but I remember it as a batch program.
Would you be able to take over stdin/out from a batch?

It's been a while since I've coded console apps, and then I've primarily used printf,cout/cin,etc.
I don't really understand how stdin/out works?

Reply 17 of 22, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie
Dacobi wrote:

Wouldn't this replace 4DOS or COMMAND.COM?

It shoudn't replace it, under the hood they are shells which sit on top of DOS and simply pipe stuff back and forth between the streams. Unless the shell program implements it's own commands like dir, type, cd etc... these are still handled by COMMAND.COM or whichever underlying OS it sits on top of.

Dacobi wrote:

My memory may be playing tricks on me, but I remember it as a batch program.
Would you be able to take over stdin/out from a batch?

Yes! It uses magic file numbers much like nix. http://steve-jansen.github.io/guides/windows- … out-stderr.html... it's the animation aspect of the prompt that I don't think can be done in a batch script though.

Dacobi wrote:

It's been a while since I've coded console apps, and then I've primarily used printf,cout/cin,etc.
I don't really understand how stdin/out works?

cout (console out) is the C++ function to send strings to stdout. aka printf in C. Likewise cerr and cin for stderr and stdin respectively. Every language will have their equiv since it is probably one of the most fundamental concepts of process/OS communications called a standard stream. https://en.wikipedia.org/wiki/Standard_streams

Reply 18 of 22, by Dacobi

User metadata
Rank Newbie
Rank
Newbie
spiroyster wrote:

simply pipe stuff back and forth between the streams.

I still don't get it, it seems recursive.

If I read cin in a cpp program how do I send that to the cin of the shell below? aren't they the same?

Or is it supposed to work using something like system(); ?

Reply 19 of 22, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie
Dacobi wrote:

Or is it supposed to work using something like system(); ?

Cando.. but it has issues. This way doesn't involve pipes at all and is probably more relevant to a shell program as it invokes the underlying command interpreter. You take your stdin from the user, and then invoke the underlying command interpreter itself passing the information as arguments, which essentially makes your shell program a transparent layer ... and means you can do what ever you want in your shell program... like animations 😉...

Only problem... output of system() would go straight to stdout, which is fine in most cases, but if you wanted to do something with the output of the invoked command from system()... like format it, colour individual chars/words or just parse it to process in some manner... you need to use pipes to hook into this ouput. The return of system() is the status code and not the output of the command unfortunately 😒 .

So on to pipes...

Dacobi wrote:

If I read cin in a cpp program how do I send that to the cin of the shell below? aren't they the same?

They have their own standard streams... the pipe is the connection between these streams. You only tend to read from cin, and write to cout/cerr. Writing to cin would probably be undefined behavoir 😲 so to send it to a child process you create a pipe from your stdout to the child process stdcin. Then when you send stuff through your stdout (which you may have read from your stdcin), it appears in the child process stdcin.

Since you seem to be somewhat familiar with c++ (you mentioned cout)

e.g
Parent program...

#include <iostream>
#include <string>

int main(int argc, char** argv)
{
std::string theInput;

std::cin >> theInput; // get the input from stdcin (user input).
std::cout << theInput; // output this to stdout.

return 0;
}

Child program...

#include <iostream>
#include <string>

int main(int argc, char** argv)
{
std::string theInput;

std::cin >> theInput; // get the input from stdcin...
// this is the piped result from previous 'parent' stdout

std::cout << "this program got the input : " << theInput;

return 0;
}

You then invoke them from DOS command line like this...

> Parent.exe | Child.exe

N.B the '|' char is the pipe and says, take stdout of Parent.exe and pipe it to stdcin of Child.exe

Output...

vogons
this program got the input : vogons

However, there are other ways, in the case of a shell program... you can't do this because the shell program is already running. So this needs to be done programmatically within your shell program... This is a lot more code and I can't be arsed to write it here.. so I will 'redirect' (or pipe you 🤣 ) to https://docs.microsoft.com/en-gb/windows/desk … nput-and-output.

Parent.exe spawns a child process (Child.exe) and then programamtically pipes to the child process stdin. This is what you would probably want for a shell program.

tbh, You don't usually mess with redirection unless you are managing child processes in programs. They are useful in scripts because scripts are mainly used to spawn child processes and the script probably wants to do something with the output.

The stdout would be the only way a script would be able to get the output of the child process, unless the child process creates a file with the output which a script reads, but both script and child program would need to both know the name/location of the resultant file... not very versatile 🙁 This is why std streams are used as no prior knowledge is required because these standard streams, which exist for every process, can be piped to and from each other.

Of course you can use files for inter-communication if you want in a shell program...

e.g

#include <cstdlib>
#include <fstream>
#include <iostream>

int main(int argc, char **argv)
{
system("dir > file.txt");

std::ifstream infile{ "file.txt" };
std::cout << infile.rdbuf();
return 0;
}

By redirecting the system() command to a file (file.txt) you can then read this file the usual way and display it's contents. This is not as elegant on the computer (creates a file, user might need admin rights), but quite elegant in code and only requires you to redirect to stdout rather than pissing about with stdin. It essentially works the same way a batch script would redirect to a file... 😉

Bit long winded answer, but I had half hour to spare... hope this helps.

Last edited by spiroyster on 2019-04-04, 21:55. Edited 1 time in total.