http://www.perlmonks.org?node_id=1038496


in reply to Re^7: What's wrong with @ARGV - or with me?
in thread What's wrong with @ARGV - or with me?

but because I much prefer cmd.exe to (z|k|z|ba)sh

I'd be interested in knowing your reasons for this. I do most of my work at a linux shell prompt, and I've never really found cmd.exe to be useful for anything other than starting console programs.

I'm not trying to start some windows vs linux flamewar here. I've only had to write a couple of batch files in the last few years, so maybe cmd.exe has more functionality now.

This is one of the uglies from my last script:

for /F "tokens=*" %%i in ('findvmip') do set vmip=%%i%

For with the bash equivalent would be a simple

vmip=`findvmip`

A quick google also still doesn't turn up any way to create functions in cmd. And command line editing functionality in cmd appears to lack a lot of the (to me) convenient bash stuff as well

So what's the thing that makes cmd preferable for you?

Replies are listed 'Best First'.
Re^9: What's wrong with @ARGV - or with me?
by cdarke (Prior) on Jun 12, 2013 at 15:39 UTC
    You've got Perl, why do you need all that other stuff from a shell?

    (Sorry to butt into a private conversation, but I couldn't help overhearing)

      Fair enough. In that case it shouldn't really matter what shell you use though, so other than perhaps for its line-editing functionality there would be no reason to prefer one over the other, right?

Re^9: What's wrong with @ARGV - or with me?
by BrowserUk (Patriarch) on Jun 12, 2013 at 20:37 UTC
    So what's the thing that makes cmd preferable for you?

    That's a really good question and one I may take some time to think abaout and come up with a more detailed answer.

    For now I'll mention 4 things:

    • It's not just one single thing, but rather the accumulation of many things.
    • I rarely ever write .bat/.cmd scripts -- a quick search showed up just 6 that I wrote and use regularly. If I need a script, I use Perl.

      Indeed, the vast majority of the .bat/.cmd files the search turned up on my system are those that are distributed with Perl itself that are produce using the pl2bat utility.

      These are weird -- and in my opinion, woeful -- hydrid scripts that contain complete perl programs wrapped over with a few lines of batch script that simple invoke perl to invoke the embedded Perl code.

      I see no purpose nor utility in this process and abhor them; any error messages they produce have the wrong line numbers; when you try to edit them, their having the wrong extension means your editor tries to apply the wrong syntax highlighting and you end up with a garbled mess; and if you edit the original .pl and then run the command you get the uneditted .bat version instead; if you try to abort them with ^C; you get a useless damn prompt asking Terminate batch job (Y/N)? which is just infuriating. Yuck!

    • In part, my preference for the simplicity of cmd.exe is related to my preference for the simplicity of my preferred editor: textpad.

      I prefer my 'simple', non-programmable editor because it is non-programmable. It is because I do not get tempted to try and perform tasks that actually require a programming language, and then waste time either jumping through hoops trying to make an inadequate tool do what I need; or having to perform a wholesale conversion to a proper programming language, once I reach the limits of the editors built-in facility.

      In the (distant) past I used various fully programmable editors; and programmed them extensively to my taste, only to find that when I no longer had access to my customised version -- as when on a customer site with protectionist policies in force; or when I changed jobs and had to use a different system were the editor I had customised was no longer available; that I had become dependent upon the things I had programmed it to do and my productively went through the floor for several weeks whilst I became used to their absence (or worse; wasted more time re-creating them as best I could in the new environment.)

      My feeling that programmable editors were more hindrance than help came a few years later when I subcontracted a guy for a month, to finish a piece of work that my workload didn't allow me time to do, and when after two weeks I asked for a progress report he had made none. I then inspected the files in hos home directores and discovered that he had literally made no changes at all to the source files he was supplied with. Further investigation -- of the nightly incremental backups -- showed that he had spent the entire 2 weeks customising the programmable editor. He'd spent his time writing reams and reams of editor scripts: to put elaborate decorations around blocks of comments; to single & double walled line-character boxes using the cursor keys; to construct and edit his timesheets; to maintain his CV -- including an entry showing his new expertise with the programmable editor!; and so on. But not a single line in any of the source files he was meant to be working on had changed.

      So it is with shells. The simpler the shell, the less likely it is that I wil be tempted to try and develop serious tools (or dog forbid, applications) using them, rather than a language (like Perl) designed for the job. Many years ago when working in a mixed NT/HP-UX environment, I developed an elaborate real-time monitoring tool using a mix of csh/sed/other *nix tools. I didn't know perl back then -- indeed, it was suggested to me and I took one look at half a dozen examples of Perl and rejected it as line noise. (In my defense, it was Perl 4 and from memory, the unknown author(s) of those examples (dug up by a altavista search) was probably no experts.

      Later when I had become a convert to Perl 5, I looked back on the extreme efforts (and hours) it had taken to get that tool working and realised just how much simpler it would have been using Perl, (probably even with Perl 4), but we live and learn.

    • Finally, I infinitely prefer the line editing, command line history and cut&paste facilities of a windowed cmd.exe session to anything available on *nix.

      In part that comes down to familiarity, but it goes much further. Every keyboard I've used in the past 20+ years has had arrow keys; home & end; delete & insert; pgup & pgdn; a set of programmable function keys. These keys perform the same tasks in just about every application I use -- pdf readers excepted. Switching from one application to another and muscle memory allows me to use them in essentially the same way everywhere. And that has been the case going right back to circa 1985 or so with the earliest versions of OS/2 that I helped develop. (And even before that with DOS to some degree; though much less so.)

      Having become used to that, every experience I have had with using *nix in various forms from HP-UX to BSD to half a dozen flavours of Linux just leaves me with finding them all wanting.

      Perhaps if I had started out using *nix at an earlier age it would be different. Having said that; my first truly programmable editor was a beast called TECO(VTEDIT) (the progenitor of EMACS) on PDP & VAX hardware running variously RSTS/E, RT11, and IAS; and nothing in this world would persuade me to go back to either it or its offspring.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
      In part, my preference for the simplicity of cmd.exe is related to my preference for the simplicity of my preferred editor: textpad. I prefer my 'simple', non-programmable editor because it is non-programmable. It is because I do not get tempted to try and perform tasks that actually require a programming language, and then waste time either jumping through hoops trying to make an inadequate tool do what I need; or having to perform a wholesale conversion to a proper programming language, once I reach the limits of the editors built-in facility.

      Ok that makes sense. For me personally there's still a vast amount of tasks that make more sense to do in the shell than in an actual program, but I can certainly understand the other opinion.

      Finally, I infinitely prefer the line editing, command line history and cut&paste facilities of a windowed cmd.exe session to anything available on *nix.

      This one does still puzzle me, because:

      Every keyboard I've used in the past 20+ years has had arrow keys; home & end; delete & insert; pgup & pgdn; a set of programmable function keys. These keys perform the same tasks in just about every application I use

      arrows,home/end,pgup/pgdown work the same in most linux terminals as in the windows commands prompt (though I do admit that some may not be set up right by default). The functions keys in the command prompt do not appear to do anything remotely similar to what they do in other apps. (F3 isn't search like it is in most apps, F4 does some delete thing which I've never seen anywhere else)

      Cut and paste is probably just familiarity; I very much prefer being able to just select with the mouse and right-click to paste over have to explictly click "mark" first.

      Command history seems a lot more powerful in bash; cmd seems limited to a simple up/down arrow? But that might be another simpler-is-better thing for you?

      Overall that was a very enlightening answer. I'd been trying to think of functionality that was _missing_ from bash, while it turned out to be not about that at all.

        This one does still puzzle me, because: arrows,home/end,pgup/pgdown work the same in most linux terminals as in the windows commands prompt (though I do admit that some may not be set up right by default).

        Really? Every *nix console I've ever tried to use generates ansi escape sequences for arrow keys etc. Whilst I did go through the process (with the help of a long-time *nix user) of trying to configure the keyboard to my expectations; we got some of it to work (kind of) and other bits never at all.

        For example:

        1. The backspace/back-arrow/run-out) key should delete the presceding character; and <delete> should delete the character under the cursor; but we could never get both to function correctly.
        2. When line-editing, ctrl + left-arrow/right-arrow move back/forward 1 "word" at a time -- these are amongst my most used keys but I never did find a way to make them work the same in a *nix shell.
        3. escape clears the command line. Never got that to work.
        4. I'm sure there were others, but my memory fails me.
        The functions keys in the command prompt do not appear to do anything remotely similar to what they do in other apps. (F3 isn't search like it is in most apps, F4 does some delete thing which I've never seen anywhere else)

        I agree that F3:search for a character in the current line; and F8:search for a previous command that begins with what you;ve currently typed; are logically transposed, but if you are used to them...

        Cut and paste is probably just familiarity; I very much prefer being able to just select with the mouse and right-click to paste over have to explictly click "mark" first.

        Go into the command window properties->defaults->options tab and select the "quick-edit mode" and you can do exactly that in every command window thence forth. (I've had it that way for so long I'd forgotten it wasn't then default. :)

        The main problem with c&p under nix shells was that they don't (or I never worked out how to make them) inter-operate with other programs. Ie. I couldn't easily copy from a shell and paste into an editor or browser; or vice versa.

        Command history seems a lot more powerful in bash; cmd seems limited to a simple up/down arrow? But that might be another simpler-is-better thing for you?

        Many people have never discovered the following functions:

        UP and DOWN ARROWS recall commands; ESC clears command line; F7 displays command history; ALT+F7 clears command history; F8 searches command history; F9 selects a command by number; ALT+F10 clears macro definitions.

        Another factor that many people miss is that cmd.exe uses multiple histories. So text entered to program prompts doesn't get mixed in with commands typed into the shell itself. And if you re-run a command, uparrow recalls text supplied to that program *only*. Run a different program that prompts for input a second time and it will recall only text entered to that program. I believe *nix programs can arrange to have their own separate histories; but if they don't you're stuffed.

        But yes, in part, it is the simplicity that I like. I just re-read a guide to bash history facilities and have trouble imagining what use I would put most of them them to -- assuming I could remember them in the first place.

        Overall that was a very enlightening answer. I'd been trying to think of functionality that was _missing_ from bash, while it turned out to be not about that at all.

        Thanks for asking a good question and avoiding the usual "my god is better than your god" argument :) It is nice to have a civilised discussion.

        Indeed, I think most people's reaction is haw could you possibly prefer something so simple minded as cmd.exe; completely missing the 'because it is simple' possibility :)


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.