Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

OT: Advantage of not expanding wildcard in the shell

by ikegami (Pope)
on Jan 28, 2005 at 15:27 UTC ( #425988=note: print w/replies, xml ) Need Help??

in reply to Re: using wildcard character * in perlscript command line
in thread using wildcard character * in perlscript command line

There is an advantage to shell not expanding wildcards. It allows for doing: copy *.txt *.bak. To do the same in a shell which expand wildcards requires a loop in the shell, making it harder to run simple commands AND duplicating the same code all over your system.

I wouldn't mind being able to do copy *.txt 's/\.txt$/.bak/'.

Replies are listed 'Best First'.
Re: OT: Advantage of not expanding wildcard in the shell
by cog (Parson) on Jan 28, 2005 at 16:32 UTC
    You just have to quote the arguments, and they won't be expanded:

    move "*.txt" "*.html"

    Of course the move command displayed here is just an example, which you'd have to code yourself...

Re: OT: Advantage of not expanding wildcard in the shell
by BrowserUk (Pope) on Jan 28, 2005 at 16:06 UTC

    Another sideeffect is that you don't end up with needing xargs or find -exec and all the similar solutions to work around wildcards that produce huge lists.

    The app. can choose--(IMO) should always choose--to use an iterator approach rather than a generator.

    Examine what is said, not who speaks.
    Silence betokens consent.
    Love the truth but pardon error.

      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.

      Makeshifts last the longest.

        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? :)

        Examine what is said, not who speaks.
        Silence betokens consent.
        Love the truth but pardon error.
Re: OT: Advantage of not expanding wildcard in the shell
by Aristotle (Chancellor) on Jan 28, 2005 at 17:16 UTC

    man 1 rename?

    For more complex cases there's the rename script distributed with Perl…

    Makeshifts last the longest.

Re: OT: Advantage of not expanding wildcard in the shell
by Tuppence (Pilgrim) on Jan 28, 2005 at 20:45 UTC
    look for '' by Larry Wall. Does exactly what you want.
Re: OT: Advantage of not expanding wildcard in the shell
by ambrus (Abbot) on Jan 28, 2005 at 21:17 UTC

    Yes, I like that great feature in dos. It even works in norton commander: you select multiple files, press F6 (rename), and type a wildcard name such as ?????_0.* to rename all selected files.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://425988]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2018-06-18 21:45 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (110 votes). Check out past polls.