Those with benchmarking experience...

If you really want to know (see 2) then why not do it yourself Benchmark made easy

Is the one line solution faster than the two line solution?

2) Do you REALLY care? Does it REALLY matter? Do you for a second think that this is likely to make any measurable difference to the execution speed of your code? It won't.

The most common similar usage is to simultateously strip leading and trailing whitespace from a string. japhy benchmarked the two line and one line examples somewhere, but due to 2) you can Super Search for that yourself :-)

To do it in one line simply need alternation with | and /g to do all two

$_ = '/////usr///bin///perl////';
s!^/+|/+$!/!g;
print $_, $/;

# but as you can see this is still broken so 
# assuming it is dealing with *nix paths
# you probably want just
$_ = '/////usr///bin///perl////';
s!/+!/!g;
print $_, $/;

# but as tr/// is faster than s/// this will probably be the winner
$_ = '/////usr///bin///perl////';
tr!/!/!s;
print $_, $/;

__DATA__
/usr///bin///perl/
/usr/bin/perl/
/usr/bin/perl/
[download]

PS The answer FWIW is that two s/// lines are marnigally faster than one s/// with alternation, but the last s/// regex example is (probably) faster than either option. tr/// will be faster again as tr/// is faster than s/// all other things being equal. Also /* is slower than /+ is slower than /{2,} becuase we only want to do a sub if we have to and we want to effectively fail fast if we have nothing that requires doing. I'll leave it to you to prove these suppositions.....

tachyon++

tr/ // is faster than s/// all other things being equal

Actually, s/// can be faster than tr/// for some tasks. I'll let you find the nodes that contain examples of that. (:

                - tye

If you want to use one regex only, you must add an alternation and thus a /g option, because you need to match two times.

$directory =~ s{ (?: ^ /* | (?<=[^/])/* $ ) }</>xg;
[download]

Update added a look-behind assertion to make the expression work in all cases. All in all, it's better with two regexes!

    s!^/*(.*[^/])/*$!/$1/!;
[download]

#!/usr/bin/perl

use strict;  
use warnings;

use Benchmark qw /timethese cmpthese/;

chomp (our @lines = <DATA>);

our (@r1, @r2, @r3);
cmpthese -10 => {
    mikedshelton  =>  '@r1 = map {local $_ = $_;
                                  s!^/*!/!;
                                  s!/*$!/!;   
                                  $_} @lines',  
    cchampion     =>  '@r2 = map {local $_ = $_;
                                  s{ (?: ^ /* | (?<=[^/])/* $ ) }</>xg
+;
                                  $_} @lines',  
    abigail       =>  '@r3 = map {local $_ = $_;
                                  s!^/*(.*[^/])/*$!/$1/!;
                                  $_} @lines',
};

die "Unequal\n" unless "@r1" eq "@r2" && "@r2" eq "@r3";

__END__
/foo/bar/baz/
foo/bar/baz/
/foo/bar/baz
foo/bar/baz
/
foo/bar
foo
[download]

                Rate    cchampion mikedshelton      abigail
cchampion     8069/s           --         -20%         -27%
mikedshelton 10038/s          24%           --          -9%
abigail      11057/s          37%          10%           --
[download]

Abigail

Misread the question

Didn't we lose the action of adding '/' when not present at the ends somewhere?   It seems that s!/{2,}!/!g; at least leaves 'foo/bar' as itself.   Which of these RE's are for explication only?

^/*(.*[^/])/*$
[download]

That will only match if the path ends in a slash. Duh! I think I checked my brain at the door. Sigh..

Makeshifts last the longest.

    $ perl -wle '"foo/bar" =~ m!^/*(.*[^/])/*$! and print "Aristotle i
+s wrong."'
    Aristotle is wrong.
[download]

Abigail

    $directory =~ s<^/*></>
               .   </*$></>;
[download]

cchampion fixed his RE so I can't explain why it doesn't work, cause now it does.

What I've been able to make work is something that recognizes the _middle_ of your string, not either end.   This is a translation out of Perl Cookbook, 2ndEd.   (cargo-cult of a higher order?)

    $directory =~ 
        s< ^  /?            # match leading '/' if present
              (             # capture what is between ends
                [^/]*       # match anything not a '/'
                (?:         # might be a '/', 
                  (?! /$ )  # but don't allow a '/' at EOL
                  .         # okay, eat the '/'
                ) *
              )
              /? $          # match trailing '/'
         >
         </$1/>x;    # now surround the middle with '/'
[download]

s { \A /*  (  (?: [^/]+ /+ )*?  [^/]*  )  /* \z }
  { length $1 ? "/$1/" : '/' }ex;
[download]

Just TIMTOWTDI:

unless ('/' eq substr($directory, 0, 1) and 
        '/' eq substr($directory, -1, 1)) { ...
[download]

I don't know how fast it is, but I generally prefer substr over RegExes in fixed-width-fixed-content problems.
Cheers,
CombatSquirrel.

---

Entropy is the tendency of everything going to hell.

What concern does that snippet address? I don't see how it has anything to do with anything posted anywhere on this thread?

As for performance, despite appearances, you're actually going to have a hard time beating the regex engine. With substr, you usually have to do a (relative) lot of explicit work in Perl code, which means many more ops to interpret; with regexen, most of the infrastructure is implicit in the guts of Perl, which execute much faster.

Makeshifts last the longest.

s/^\//; { local $/='/'; chomp; }
[download]

Didn't read the question correctly the first time. Sorry.

I added a feature to my site map utility that does that. My routine is much more complex than what others have posted so far, and handles directory detection in some cases by comparing webpages retrieved through URLs with and without a trailing slash. A slashed target would break some links that end with a file, and some URL's point to an extensionless file that looks like a directory. My code is proprietary, but the instructions in the configuration utility currently read:

Slash Directory
Type yes to append a slash to each link target that points to a directory, when a trailing slash isn't already present (speeds loading of target page). Extensionless files will be detected and not slashed. Otherwise, type no or leave blank.

Slash Base
Type yes to append a slash to each link target that points to a base directory (domain name), when a trailing slash isn't already present. Otherwise, type no or leave blank. Targets that specify a home page's file, such as domain.com/index.html, will not be slashed. This feature adds consistency to link targets, but does not speed loading of target page.