Re^2: OT: Advantage of not expanding wildcard in the shell

[Aristotle]

Of course that also means the overwhelming majority of commands on Windows only take a single file as parameter and do not expand wildcards, because the programmer didn't know how or couldn't be bothered to go through the trouble (considering that FindFirst/FindNext API, I can sympathize). So you end up with a DEL command you have to write a loop around if you want to delete more than one file. Even when coammds do take wildcards, you often end up having to write loops: there is no way to write the equivalent of cp *.pl *.pm *.html projects/foowebapp/ because COPY expects exactly one source argument, whether it's a wildcard or not.

At least there are replacement shells like 4DOS which fix the builtins.

[BrowserUk]

Actually DEL does take multiple arguments since the last 10 years or so:

[17:31:36.94] P:\test\tmp>dir /b
bill
fred
joe.1
joe.2

[17:31:39.70] P:\test\tmp>del fred bill joe.*

[17:31:53.30] P:\test\tmp>dir /b

but there is no direct equivalent of the cp command you showed. Tt can easily be done as "one line".

subst x: projects/foowebapp/ & copy *.pl x: & copy *.pm x: & copy *.ht
+ml x: & subst x: /d

# Or
 
for %i in (*.pl *.pm *.html) do @copy %i projects/fooweebapp/

Not as nice I agree, but neither will ever break if the number of files that match, grows above some arbitrary number.

Basically, you win some and you lose some.

As for 4DOS, I find that it has even more special cases, and caveats than most unix shells.

Don't get me wrong!. When I stand behind a bash or even a c-shell expert and watch them do things, I am amazed at the engenuity with which they can do things right there, without reaching for a script.

That said, it often takes them several attempts to get the commands right, and often requires them to look up the paramaters to one or more of the commands along the way.

And that's kind of where I sit with shell scripting--it is usually easier (for me) to reach for a scripting tool, like Perl or REXX, than to piece together all the bits I need from the shell language and syntax. It also has the advantage of retaining the code developed for next time.

I have a similar attitude about editors. You can do just about anything you like from with emacs. The problem comes when you don't have (or are not allowed to use) your own, highly configured version of that editor.

I have tried, and become dependant upon several, very sophisticated editors down the years--teco, VMS edit, e3 and a few others I've forgotten the names of--but each of them became unavailable to me as I moved from one environment to another. I arrived at conclusion that a fairly simple editor is prefereable. (That doesn't mean notepad though :)

And I could not live without my set of unix-tools.

But as strange as it may seem, the main reason I choose not to use linux, is because I *really* don't like the shells. I prefer cmd.exe to all of those I have tried. I hear great things about zsh, but I have never used it--and I doubt that it would respond "properly" to the cursor keys-insert/delete/home/end/pgup/pgdn etc. and that is the biggest single bugbear for me of the unix shells.

Maybe I should write a cmd.exe clone for linux--do you think I would get many takers? :)

[Aristotle]

neither will ever break if the number of files that match, grows above some arbitrary number.

Well, when working with find, xargs is a natural choice anyway. And I've only ever needed to reach for xargs once where I wouldn't otherwise have just because the number of files in a single directory had grown too large.

it is usually easier (for me) to reach for a scripting tool, like Perl or REXX, than to piece together all the bits I need from the shell language and syntax.

That's a matter of practice. If you keep avoiding shell, you'll never learn it, and the things shell does well cost much more effort to do with a more fully featured language like Perl, so on the bottom line you are wasting a lot of energy. (Cf. false laziness.) But if you don't need it often to begin with, then again it's a wasted investment indeed.

The phenomenon that it takes even a well versed shell user a few tries to piece a complex command together is pretty common; but I like doing it that way. To quote Larry, “The fact that it takes a little hard work from the programmer to make the computer do hard work should not be a consideration when the payoff is big.”

You can do just about anything you like from with emacs. The problem comes when you don't have (or are not allowed to use) your own, highly configured version of that editor.

That was one of the two primary motivations for my sticking with a vi, namely, Vim (the other being that vi's model of thinking about text manipulation feels like a closer match to how I think when I edit, though modal editing still takes getting used to at first). While working without my .vimrc on foreign system is sometimes annoying, it is not a real problem: the default configuration is extensive and pretty sensible so just give me a vi and I'm ready to rumble. If in the course of a task I really miss some personal settings then they're easy to reconstruct anyway, since any task only involves a subset of all of my preferred options. Reconstructing it just takes a few quick :sets.

The choice has served me so well already in the few years since I made it that I'm at least as fanatical about Vim as I am about Perl. First thing I do on any machine I have to work on is install Vim if it's not there already. And Vim is available for just about every possible platform with a full-sized keyboard. I don't expect to ever be stranded without it regardless of where time takes me, as oposed to other great but platform specific editors.

If you haven't made a serious attempt to get accustomed to it, do yourself a favour and try it.

[BUU]

But as strange as it may seem, the main reason I choose not to use linux, is because I *really* don't like the shells. I prefer cmd.exe to all of those I have tried. I hear great things about zsh, but I have never used it--and I doubt that it would respond "properly" to the cursor keys-insert/delete/home/end/pgup/pgdn etc. and that is the biggest single bugbear for me of the unix shells.

(Since we're ridiculously off topic anyways)

If your shell isn't responding to home/pgdn/pgup/etc keys, thats merely a configuration issue with how the kernel (I think) treats the keycodes your keyboard sends, for example change .inputrc, which is fairly trivial, it has nothing to with the shell. My bash, on linux for example, respondes perfectly to the various insert, delete and etcetera keys.

[Aristotle]

Actually, it's not the kernel, it's the fact that Unix has a much greater legacy than just a box with one user and a keyboard attached to it. In the Unix world, a keypress doesn't just diddle a few bits on a hardware port which you poll with a system call. It's communicated as part of a complex protocol implemented by the terminal you use. Applications read a raw protocol stream from STDIN and are expected to interpret it; this is where termcap or friends and all that devil's work comes in.

I understand the whole shebang just well enough to make it work and then supress any memory of it. :-) Things seem to have gotten far, far better in this respect in recent years, though, with most stuff working out of the box. The effort this takes on the distributors' side should not be underestimated.

Your post is partially correct in that the Linux kernel does implement a terminal for the text mode consoles, though.