What happens if you have two commands that get 'perlified' to the same name?

use Shell 'foo.bar', 'foo-bar';
[download]

Perhaps the import should die in that case. To accomodate this need, perhaps you could allow an explicit mapping?

use Shell 
    # Command      # sub name  
    ['foo.bar'  => 'foo_dot_bar' ], 
    [ 'foo-bar' => 'foo_dash_bar'],
    [ $^O =~ /Windows/ 
      ? 'copy' 
      : 'cp'    => 'cp'
    ];
[download]

Thats a better solution to the problem (mine causes c++ to become 'c__', which is just too cryptic).

If explicit remapping were available, should the automagic remapping of ugly characters to underscore be kept? I'm leaning towards no.

Also, why choose an alist over a hash? Just a style thing? (Update: nevermind, I see now that it allows you to map a shell name to multiple perl names elegantly)

Update 2: Here's the patch:

--- Shell.pm.old    2008-07-08 12:09:00.000000000 -0700
+++ Shell.pm    2008-07-08 19:28:17.000000000 -0700
@@ -21,8 +21,14 @@
         @EXPORT = 'AUTOLOAD';
     }
     foreach my $sym (@EXPORT) {
+        my ($shellsym, $perlsym);
+        if (ref $sym and ref $sym eq 'ARRAY') {
+            ($shellsym, $perlsym) = @$sym;
+        } else {
+            $shellsym = $perlsym = $sym;
+        }
         no strict 'refs';
-        *{"${callpack}::$sym"} = \&{"Shell::$sym"};
+        *{"${callpack}::$perlsym"} = \&{"Shell::$shellsym"};
     }
 }
[download]

Why an array list rather than a hash? Um, it just seemed right at the time... I like your answer better than mine :).

I thought about passing a hash ref with all the maps, but intuitively, a list of arrays felt better. I didn't think about why, but just wrote it that way. Probably not the best engineering method on my part.

Take my ideas with a grain of salt, as I haven't ever used Shell.pm. But I do think it's a neat demonstration of some very useful Perl techniques.

It seems to me that Shell.pm is all about friendly magic. And, I think the automatic mapping idea is a really good bit of friendly magic. For that reason, I'd keep the automatic mapping for items specified as strings as needed. Perhaps you could throw a warning when you have to do a translation. If you're feeling like getting really fancy, I think there's a way to register the warning so it can be controlled with the warnings pragma. That way the warning could be disabled with:

no warnings 'shell_automapping';
use Shell 'foo.bar';
[download]

I've never figured out how to do that though, and its certainly a more complex bit of work.

Any explicit mapping should be honored and no automatic mapping should occur for an explicitly mapped item.

Any name collisions should cause the import to throw a fatal exception.

But all I'm doing is jawing. You are writing actual code, so I'll just shut up now and let you get some work done. :)


TGI says moo

As far as name clashes go: you're explicitly asking for one command, so thats probably the one you want to use

Very good. Obviously I don't know enough about Shell.pm, so disregard my comment ;-)

I would also tend to question the sanity of a system that had programs with such similar names yet differing functionality.

Me too, but as a module author you're in no position to judge your user's sanity, or the sanity of their systems.

I hadn't thought of '+', because it hadn't come up for me yet. Thanks.

If you want to do it properly, either look into the source code of a POSIX compatible shell or in the POSIX standard itself to get a list of all characters that can be used in commands without the need for escaping. On thinking a bit more I remember that there's /usr/bin[ on my system (for stuff like if [ .. ], so there could well be many other allowed characters.

Maybe just substitute anything but [a-zA-Z0-9_] with underscores?