[Tutor] Cmd Advice

[Dave Angel]

On 02/11/2012 06:46 AM, Dave Hanson wrote:
> On Sat, Feb 11, 2012 at 11:35 AM, Dave Angel<d at davea.name>  wrote:
>
>> (Please don't top-post.  Please put your comments after whatever parts
>> you're quoting (replying to) )
>>
> Apologies Dave.
>
>
>> You need to learn how to create a DOS window (or cmd window, just another
>> name for same thing) in Windows.  One way is to use the RUN prompt in the
>> Start menu, and run the program  CMD.  Another is to go to the Start
>> Menu->Accessories->DOS box.  it's been a long time since I ran Windows, so
>> it may have some different name, but it should be in your accessories
>> somewhere.  Since I use such a shell constantly, I created a shortcut key
>> to open one.
>>
>> Once you do that, you should see a "box" with a C: prompt.  It is indeed
>> black, but you can customize it in many ways.  From there you can type all
>> the commands that Walter was telling you about.  And it normally won't go
>> away when a program finishes running, so you don't have the "black and
>> appears for a millisecond" syndrome.
>>
>> Windows will create one of these if you run console things from the GUI,
>> but it also destroys them as soon as the program ends.
>>
>> --
>>
>> DaveA
>>
>>   I did mention very early on in my query that I had restricted access to
> the Dos CMD prompt, hence why I asked if anyone knew how to create a self
> contained prompt within the Python program. I was under the impression that
> the .bat file Walter described would fill that gap.
>
> Thanks for your comments too, but your solution unfortunately is not one I
> can use as I cannot do all the usual methods to run the Dos prompt, .bat
> files are not a problem, I have used several in the past. My issue is that
> I cannot give commands directly to the Dos prompt and in turn not "operate"
> the python program as I can on my Ubuntu machine.
>

You still don't say "why" you can't get a traditional DOS prompt.  If 
your Windows is somehow constrained (e.g. company rules) or broken (e.g. 
somebody deleted some of the dll's in Windows/system32), then it's 
unclear how we're supposed to guess just which things are going to work 
in it.  it's also unclear whether it's the programmer's machine (yours) 
that's constrained or only the end user.

In Windows, whenever a console program is launched without a console, 
one is created for that program.  It goes away when the program ends, so 
it's not real useful for learning and experimentation.  However, it does 
last as long as the program does, so you can just use raw_input to  
print your "prompt" and accept commands.  Just remember you may want to 
add another one at the end so the user gets a chance to read the last 
stuff you printed.

CMD is the cononical way to launch such a window, and batch files use 
CMD by default.  So a batch file is one back-door.  But you can write 
your own shell in any programming language you like, and if don't mark 
it as a GUI app, it'll get a DOS box as well.  You can launch programs, 
including Python programs, from your own shell.  And they'll normally 
continue to use the same shell as your launcher.

Perhaps you didn't realize that CMD takes some command switches of its 
own.  One of them tells it to stick around even when the current batch 
file ends.

Random thoughts for an incompletely specified set of constraints.


-- 

DaveA