Looking for a renaming tool with certain capabilities, but when
googling or searching cpan its quite hard to tell if the tool can or
not satisfy them. So, I hope someone can tell me right off the top of
their head if there is a renaming tool on cpan or anywhere else for
that matter that can handle ny specifications:

(This tool will be used against images with fixed extensions)

1) Handle windows style names with spaces, but not itself create such
names.

2) Generate random names for each file with the least number of
characters possible to generate a given number of names.
Names can be alph-numeric and should be no longer than necessary to
generate the needed number of names (Which will be known in advance)

I've seen quite a few different renaming tools, not necessarily perl
tools, but they seem to all stick to something of a certain set of
options for Image naming. These revolve around various numbering
schemes, mostly some kind of sequential with varying number of digits,
insert specific text, and keep extension either upper or lower case.

I have need of generating names that are random, no sequence, but of
course the extension would remain the same.

So in summary, a renaming tool that can handle windows file naming
conventions and generate random names (except the extension)

Can anyone suggest a tool they know to be capable of the above?


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

At 8:41 PM -0600 1/31/11, Harry Putnam wrote:
>Looking for a renaming tool with certain capabilities, but when
>googling or searching cpan its quite hard to tell if the tool can or
>not satisfy them. So, I hope someone can tell me right off the top of
>their head if there is a renaming tool on cpan or anywhere else for
>that matter that can handle ny specifications:
>
>(This tool will be used against images with fixed extensions)
>
>1) Handle windows style names with spaces, but not itself create such
> names.
>
>2) Generate random names for each file with the least number of
> characters possible to generate a given number of names.
> Names can be alph-numeric and should be no longer than necessary to
> generate the needed number of names (Which will be known in advance)
>
>I've seen quite a few different renaming tools, not necessarily perl
>tools, but they seem to all stick to something of a certain set of
>options for Image naming. These revolve around various numbering
>schemes, mostly some kind of sequential with varying number of digits,
>insert specific text, and keep extension either upper or lower case.
>
>I have need of generating names that are random, no sequence, but of
>course the extension would remain the same.
>
>So in summary, a renaming tool that can handle windows file naming
>conventions and generate random names (except the extension)
>
>Can anyone suggest a tool they know to be capable of the above?

You are not likely to find such a specific tool. However, you can
develop your own tool.

Here is a renaming program adapted from the one in the Perl Cookbook,
Recipe 9.9:

#!/usr/bin/perl
#
# rename
#
# perl script to rename files
#
# Usage:
#
# rename perlexpr [files]
#

($op = shift) ||
die
"Usage: rename perlexpr [filenames]
where perlexpr is any perl expression that modifies \$\_:
's/old/new/'
'\$\_ .= \".ext\"'
'tr[A-Z][a-z]'\n";

if( ! [at] ARGV ) {
[at] ARGV = <STDIN>;
chop( [at] ARGV );
}
for( [at] ARGV ) {
$was = $_;
eval $op;
die $ [at] if $ [at] ;
rename($was,$_) unless $was eq $_;
}


The perlexpr can be as complicated as you want it, using the s///e
modifier to introduce arbitrary Perl code into your replacement
string. Of course, if you have some method for renaming files, it
would be easier to use if you programmed it into your script.

I would add a test to see if a file already exists with the target
name before renaming the file and overwriting an existing file.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Jim Gibson wrote:
>
> You are not likely to find such a specific tool. However, you can
> develop your own tool.
>
> Here is a renaming program adapted from the one in the Perl Cookbook,
> Recipe 9.9:
>
> #!/usr/bin/perl
> #
> # rename
> #
> # perl script to rename files
> #
> # Usage:
> #
> # rename perlexpr [files]
> #
>
> ($op = shift) ||
> die
> "Usage: rename perlexpr [filenames]
> where perlexpr is any perl expression that modifies \$\_:
> 's/old/new/'
> '\$\_ .= \".ext\"'
> 'tr[A-Z][a-z]'\n";

You should use a here doc so you don't have to backslash everything:

my $op = shift or die <<'USAGE';
Usage: rename perlexpr [filenames]
where perlexpr is any perl expression that modifies $_:
's/old/new/'
'$_ .= ".ext"'
'tr/A-Z/a-z/'
USAGE


> if( ! [at] ARGV ) {
> [at] ARGV = <STDIN>;
> chop( [at] ARGV );

You should use chomp instaed of chop:

chomp( [at] ARGV = <STDIN> );


> }
> for( [at] ARGV ) {
> $was = $_;
> eval $op;
> die $ [at] if $ [at] ;
> rename($was,$_) unless $was eq $_;
> }

That looks a lot like Larry's rename script which is distributed with
some versions of Linux.



John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 01/02/2011 02:41, Harry Putnam wrote:
> Looking for a renaming tool with certain capabilities, but when
> googling or searching cpan its quite hard to tell if the tool can or
> not satisfy them. So, I hope someone can tell me right off the top of
> their head if there is a renaming tool on cpan or anywhere else for
> that matter that can handle ny specifications:
>
> (This tool will be used against images with fixed extensions)
>
> 1) Handle windows style names with spaces, but not itself create such
> names.
>
> 2) Generate random names for each file with the least number of
> characters possible to generate a given number of names.
> Names can be alph-numeric and should be no longer than necessary to
> generate the needed number of names (Which will be known in advance)
>
> I've seen quite a few different renaming tools, not necessarily perl
> tools, but they seem to all stick to something of a certain set of
> options for Image naming. These revolve around various numbering
> schemes, mostly some kind of sequential with varying number of digits,
> insert specific text, and keep extension either upper or lower case.
>
> I have need of generating names that are random, no sequence, but of
> course the extension would remain the same.
>
> So in summary, a renaming tool that can handle windows file naming
> conventions and generate random names (except the extension)
>
> Can anyone suggest a tool they know to be capable of the above?

Hey Harry

As Jim says, there is very little chance that you will find an existing
module that conforms to such a tight specification, but such a facility
is trivial to write. Take a look at the program below and see if it
helps you with a solution.

HTH,

Rob


use strict;
use warnings;

use List::Util qw/shuffle/;

sub digits_for {
my $n = shift;
return $n < 36 ? 1 : 1 + digits_for($n/36)
}

sub base36 {
my ($n, $digits) = [at] _;
my $b36 = '';
while ($digits > 0) {
my $d = $n % 36;
$d = chr($d + ord('A') - 10) if $d >= 10;
$b36 = $d.$b36;
$n = int $n / 36;
$digits--;
}
return $b36;
}

sub name_list {
my $num = shift;
my $digits = digits_for($num);
my $max = 0;
$max = $max * 36 + 35 for 1..$digits;
my [at] list = map base36($_, $digits), (shuffle 0 .. $max)[0..$num-1];
return \ [at] list;
}

chdir 'path/to/directory' or die $!;

opendir my $dh, '.' or die $!;
my [at] names = grep { not /\A\.\.?\z/ and -f } readdir $dh;
closedir $dh;

my $newnames = name_list(scalar [at] names);

foreach my $name ( [at] names) {
(my $newname = $name) =~ s/.*(\..*)/pop( [at] $newnames).$1/e;
printf "%s => %s\n", $name, $newname;
rename $name, $newname;
}

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Jim Gibson <jimsgibson [at] gmail.com> writes:

[...]

"John W. Krahn" <jwkrahn [at] shaw.ca> writes:

[...]

Rob Dixon <rob.dixon [at] gmx.com> writes:

[...]

I had roughed out something that worked (sort of) and so found some of
the problems that come up (such as overwriting).

With the excellent input provided from the above cited posts, I can
now manage a pretty nice and at least partially well written program
where I've followed the leads provided.

I might even get through it without having leveled ~/ or worse, clear
down to `/' while tinkering ... Thanks.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2011-02-01 03:41, Harry Putnam wrote:

> Can anyone suggest a tool they know to be capable of the above?

Get inspired by the rename script, that comes with every perl installation.

http://search.cpan.org/~rmbarker/File-Rename/rename.PL

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Rob Dixon <rob.dixon [at] gmx.com> writes:

> Hey Harry
>
> As Jim says, there is very little chance that you will find an existing
> module that conforms to such a tight specification, but such a facility
> is trivial to write. Take a look at the program below and see if it
> helps you with a solution.

[...] Skipped nifty script

First off, this program appears to work flawlessly.

I'm really not able to follow the code very far at all.

I wonder why it appears to favor uppercase, or really even use
uppercase at all. And I was pleasantly surprised with the brevity of
the names produced.

I don't see where in the code that upper case happens.

I'd like to stop it creating any uppercase....not as an urgent
necessity but just for ease all around when or if it becomes necessary
to type any names. But maybe excluding uppercase would shrink the
pool of possible characters too much?

I'd also like to introduce a very thin check on the file types, but
confine the check just to mechanically examining the extension. Not
try to verify that it is in fact an image file. That should not be
necessary but there is some likelyhood of discovering a typo or
possibly hit some rare types of image format.

I used this in my crude little starter program as one part of a
foreach loop:

if ( !/^.*\.[bjgtp][gimnps][gfadp]$/) {
print "<$_> is not a properly named image file .. skipping\n";
next;
}

Just so I'd have output so as to trace any problematic files if there
seemed a need. The regex appears to encompass all the types I want to
deal with, but is no doubt horribly written.

Its intended to allow:

jpg, tif, bmp, gif, tga, png, psd And to reject anything else and just
skip it. I think that's all, but may be leaving out some less common
types. I'd sooner only deal with types listed there.

Gettng back to your code... to tell the truth, I'm pretty much
mystified by it.... I haven't looked at any perl for several months
and have been busy as a videographer.

Taxing your patience a bit, but if you are willing to do still more
hand holding, I would benefit a lot if you were to comment the code
enough so I could follow the purpose of each major section.



--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

At 9:47 AM -0600 2/3/11, Harry Putnam wrote:
>Rob Dixon <rob.dixon [at] gmx.com> writes:
>
>> Hey Harry
>>
>> As Jim says, there is very little chance that you will find an existing
>> module that conforms to such a tight specification, but such a facility
>> is trivial to write. Take a look at the program below and see if it
> > helps you with a solution.
>
>[...] Skipped nifty script
>
>First off, this program appears to work flawlessly.
>
>I'm really not able to follow the code very far at all.
>
>I wonder why it appears to favor uppercase, or really even use
>uppercase at all. And I was pleasantly surprised with the brevity of
>the names produced.
>
>I don't see where in the code that upper case happens.

This line assigns an upper-case letter to $d if $d has a value
greater than or equal to 10. A value of 10 is replaced by 'A', 11 by
'B', etc.

$d = chr($d + ord('A') - 10) if $d >= 10;

You can try changing that 'A' to 'a' and see what you get. I haven't
tried to comprehend the rest of the logic of Rob's program, but that
line stands out like a sore thumb when it comes to "uppercase".

--
Jim Gibson
Jim [at] Gibson.org

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Feb 3, 2011 at 10:47 AM, Harry Putnam <reader [at] newsguy.com> wrote:
> I used this in my crude little starter program as one part of a
> foreach loop:
>
> =C2=A0if ( !/^.*\.[bjgtp][gimnps][gfadp]$/) {
> =C2=A0 =C2=A0print "<$_> is not a properly named image file .. skipping\n=
";
> =C2=A0 =C2=A0next;
> =C2=A0}
>
> Just so I'd have output so as to trace any problematic files if there
> seemed a need. =C2=A0The regex appears to encompass all the types I want =
to
> deal with, but is no doubt horribly written.
>
> Its intended to allow:
>
> jpg, tif, bmp, gif, tga, png, psd And to reject anything else and just
> skip it. =C2=A0I think that's all, but may be leaving out some less commo=
n
> types. =C2=A0I'd sooner only deal with types listed there.

unless($filename =3D~ m(.+\.(bmp|gif|jpg|png|psd|tga|tif)$))
{
print STDERR "The filename {$filename} has an unsupported
extension. Skipping...";
next;
}


--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence=
..org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Brandon McCaig <bamccaig [at] gmail.com> writes:

> On Thu, Feb 3, 2011 at 10:47 AM, Harry Putnam <reader [at] newsguy.com> wrote:
>> I used this in my crude little starter program as one part of a
>> foreach loop:
>>
>>  if ( !/^.*\.[bjgtp][gimnps][gfadp]$/) {
>>    print "<$_> is not a properly named image file .. skipping\n";
>>    next;
>>  }
>>
>> Just so I'd have output so as to trace any problematic files if there
>> seemed a need.  The regex appears to encompass all the types I want to
>> deal with, but is no doubt horribly written.
>>
>> Its intended to allow:
>>
>> jpg, tif, bmp, gif, tga, png, psd And to reject anything else and just
>> skip it.  I think that's all, but may be leaving out some less common
>> types.  I'd sooner only deal with types listed there.
>
> unless($filename =~ m(.+\.(bmp|gif|jpg|png|psd|tga|tif)$))
> {
> print STDERR "The filename {$filename} has an unsupported
> extension. Skipping...";
> next;
> }

Thanks for the suggestion.

May I ask how that formulation servers the purpose better? Is it
processed more easily or quicker in that formulation as against the
one I posted?

Or does mine leave too many possibilities for poor results?


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Jim Gibson <jimsgibson [at] gmail.com> writes:

> This line assigns an upper-case letter to $d if $d has a value greater
> than or equal to 10. A value of 10 is replaced by 'A', 11 by 'B', etc.
>
> $d = chr($d + ord('A') - 10) if $d >= 10;
>
> You can try changing that 'A' to 'a' and see what you get. I haven't
> tried to comprehend the rest of the logic of Rob's program, but that
> line stands out like a sore thumb when it comes to "uppercase".

Thanks for the tip.

Changing to lowercase (`a') as you suggested fixed it so no uppercase
letters appear now.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Thu, Feb 3, 2011 at 4:59 PM, Harry Putnam <reader [at] newsguy.com> wrote:
> May I ask how that formulation servers the purpose better? =C2=A0Is it
> processed more easily or quicker in that formulation as against the
> one I posted?
>
> Or does mine leave too many possibilities for poor results?

Yours just wasn't very precise:

> if ( !/^.*\.[bjgtp][gimnps][gfadp]$/) {

Instead of specifying valid extensions, you're specifying valid
first-characters, valid second-characters, and valid third-characters
for the file extension. Pick any random character from each bracket
expression (i.e., '[expression]') and you can generate file names that
would match and shouldn't. For example:

foo.jga
bar.ppp
baz.gma

Obviously not what you intended to match, but they will match
(untested). Using a full literal string for the extension means that
it needs to match the whole thing exactly. The alternation character
(i.e., '|') allows you to specify one of many valid options to choose
from. I find it rather luxurious. I know that other regular expression
engines seem to only permit first|second whereas Perl seems to allow
"any number"[1] of choices, which provides a lot more powerful
expressiveness.

In addition to the stricter matching rules, it's also rather more easy
to read, IMHO. Looking at my regular expression, it should be obvious
to any programmer and many computer users that it's matching image
file extensions. Yours appears much more random to a human. It might
suggest that it's matching file extensions, but it certainly doesn't
communicate well which ones it is supposed to match.

[1] I don't know if it's actually "unlimited" or not.


--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence=
..org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Brandon McCaig <bamccaig [at] gmail.com> writes:

> On Thu, Feb 3, 2011 at 4:59 PM, Harry Putnam <reader [at] newsguy.com> wrote:
>> May I ask how that formulation servers the purpose better?  Is it
>> processed more easily or quicker in that formulation as against the
>> one I posted?
>>
>> Or does mine leave too many possibilities for poor results?
>
> Yours just wasn't very precise:
>
>> if ( !/^.*\.[bjgtp][gimnps][gfadp]$/) {
>
> Instead of specifying valid extensions, you're specifying valid
> first-characters, valid second-characters, and valid third-characters
> for the file extension. Pick any random character from each bracket
> expression (i.e., '[expression]') and you can generate file names that
> would match and shouldn't. For example:
>
> foo.jga
> bar.ppp
> baz.gma

[...]

> In addition to the stricter matching rules, it's also rather more easy
> to read, IMHO. Looking at my regular expression, it should be obvious
> to any programmer and many computer users that it's matching image
> file extensions. Yours appears much more random to a human. It might
> suggest that it's matching file extensions, but it certainly doesn't
> communicate well which ones it is supposed to match.

Nicely put... and thanks for the effort to explain it.

One further question. In your formulation shown below:
,----
| unless($filename =~ m(.+\.(bmp|gif|jpg|png|psd|tga|tif)$))
| {
| print STDERR "The filename {$filename} has an unsupported
| extension. Skipping...";
| next;
| }
`----

I see that specifying exact possible extensions is good, but don't
really see what the `m' does there. I'm not that informed on all
incantations of perl regex but does that not anticipate filenames
using multiple lines?

My take on `m' (from perlre) is that it basically replaces the meaning
of ^ and $ from the common start of string and end of string, to start
and end of any line anywhere in multiple lines.

Further it seems that the use of parens for regex delimiters (at least
in this instance) is somewhat confusing when its thrown in with at
least 2 other uses of parens, making 3 different kinds of uses in one
clause.

Its used to enclose arguments to a function, to enclose uses of the
alternation char, and to delimit a regex.

And finally the `.+' at the start of the regex seems to allow names
such as $$.psd or ##.psd or %.psd and the like. Kind of undoing your
effort to enforce strict extensions by allowing weird and even
unusable names on the other end.

Would `\w+' have served better or am I really missing the boat all
the way round?


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2/4/11 Fri Feb 4, 2011 8:02 AM, "Harry Putnam" <reader [at] newsguy.com>
scribbled:

>
> One further question. In your formulation shown below:
> ,----
> | unless($filename =~ m(.+\.(bmp|gif|jpg|png|psd|tga|tif)$))
> | {
> | print STDERR "The filename {$filename} has an unsupported
> | extension. Skipping...";
> | next;
> | }
> `----
>
> I see that specifying exact possible extensions is good, but don't
> really see what the `m' does there. I'm not that informed on all
> incantations of perl regex but does that not anticipate filenames
> using multiple lines?

The leading 'm' is "match" operator. It is optional if you use
forward-slashes as the regex delimiter. Including an explicit 'm' to start
the regex allows you to use any matched set of delimters (e.g. '()', '{}'
'[]', '||', etc.). Since parentheses are used in the above regex, the 'm' is
required here.

See 'perldoc perlop' and search for "Regexp Quote-Like Operators".

>
> My take on `m' (from perlre) is that it basically replaces the meaning
> of ^ and $ from the common start of string and end of string, to start
> and end of any line anywhere in multiple lines.

That is correct for a trailing 'm'.

>
> Further it seems that the use of parens for regex delimiters (at least
> in this instance) is somewhat confusing when its thrown in with at
> least 2 other uses of parens, making 3 different kinds of uses in one
> clause.

You can use other characters to make it more readable. However, all of the
normal delimiters such as {} and [] have other meanings within the regular
expression. Some overlap of meaning is unavoidable, and context-awareness is
required on the part of the reader.

> And finally the `.+' at the start of the regex seems to allow names
> such as $$.psd or ##.psd or %.psd and the like. Kind of undoing your
> effort to enforce strict extensions by allowing weird and even
> unusable names on the other end.

I think that the '.+' is not necessary and only requires that at least one
character appear before the period in the file name. The same effect would
be achieved with a single '.' character. Leaving it off entirely would mean
that names such as '.jpg' and '.png' would match.

>
> Would `\w+' have served better or am I really missing the boat all
> the way round?
>

It all depends upon what you want to match and what you want to exclude.
Some file names will not be matched by \w+\.(jpg|png|...)

The only improvement I could suggest (and it is only a small difference in
speed) is to make the grouping parentheses non-capturing:

m(.\.(?:bmp|gif|jpg|png|psd|tga|tif)$)

You can also use extend syntax and the \z zero-width assertion to make your
regex more readable:

m{ . \. (?: bmp|gif|jpg|png|psd|tga|tif ) \z }x




--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Jim Gibson <jimsgibson [at] gmail.com> writes:

> On 2/4/11 Fri Feb 4, 2011 8:02 AM, "Harry Putnam" <reader [at] newsguy.com>
> scribbled:
>
>>
>> One further question. In your formulation shown below:
>> ,----
>> | unless($filename =~ m(.+\.(bmp|gif|jpg|png|psd|tga|tif)$))
>> | {
>> | print STDERR "The filename {$filename} has an unsupported
>> | extension. Skipping...";
>> | next;
>> | }
>> `----

[...] snipped very helpful detailed explanations

> You can use other characters to make it more readable. However, all of the
> normal delimiters such as {} and [] have other meanings within the regular
> expression. Some overlap of meaning is unavoidable, and context-awareness is
> required on the part of the reader.

I notice that in the OPs code and in your examples, the forward slash
is not used at all.... When you say above that "all the normal
delimiters [...]" .. but forward slashes `//' do not have special
meaning inside and would seem then to be ideal char for delimiters.

Yet they seem to be carefully avoided. That is what I nearly always
use. Is there some reason to avoid `//' as delimiters?

[...]

>> Would `\w+' have served better or am I really missing the boat all
>> the way round?
>>
>
> It all depends upon what you want to match and what you want to exclude.
> Some file names will not be matched by \w+\.(jpg|png|...)

Do you mean legitimate Image files? Can you give an example... I'm
not visualizing what they would look like.

ps - Thanks for the detailed explanations of the finer points.


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "HP" == Harry Putnam <reader [at] newsguy.com> writes:

HP> Jim Gibson <jimsgibson [at] gmail.com> writes:
>> On 2/4/11 Fri Feb 4, 2011 8:02 AM, "Harry Putnam" <reader [at] newsguy.com>
>> scribbled:

>> You can use other characters to make it more readable. However, all
>> of the normal delimiters such as {} and [] have other meanings
>> within the regular expression. Some overlap of meaning is
>> unavoidable, and context-awareness is required on the part of the
>> reader.

HP> I notice that in the OPs code and in your examples, the forward slash
HP> is not used at all.... When you say above that "all the normal
HP> delimiters [...]" .. but forward slashes `//' do not have special
HP> meaning inside and would seem then to be ideal char for delimiters.

they are called slashes. there is no forward slash. wipe that term from
your memory. there is a backwards slash. slash has always been slash and
should stay that way regardless of its abuse by redmondware.

HP> Yet they seem to be carefully avoided. That is what I nearly always
HP> use. Is there some reason to avoid `//' as delimiters?

no. you should // in most cases. you should change to alternate
delimiters (for all delimited string like things) when the default
delimiter is in the string itself. or in some cases with regexes like
with /x (extended mode) it is easier to deal with other delims. and the
best choice for alternate delims are paired ones, in particular {}.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Fri, Feb 4, 2011 at 12:43 PM, Harry Putnam <reader [at] newsguy.com> wrote:
> I notice that in the OPs code and in your examples, the forward slash
> is not used at all.... When you say above that "all the normal
> delimiters [...]" .. but forward slashes `//' do not have special
> meaning inside and would seem then to be ideal char for delimiters.
>
> Yet they seem to be carefully avoided. =C2=A0That is what I nearly always
> use. =C2=A0Is there some reason to avoid `//' as delimiters?

The reason that I didn't use forward^Wslashes is because I often use
regular expressions with file system paths and usually end up with
leaning toothpicks[1]. I'm more or less just experimenting with other
delimiters so that I'll remember that I can when it's actually useful.
:-X

[1] http://en.wikipedia.org/wiki/Leaning_toothpick_syndrome

--
Brandon McCaig <http://www.bamccaig.com/> <bamccaig [at] gmail.com>
V zrna gur orfg jvgu jung V fnl. Vg qbrfa'g nyjnlf fbhaq gung jnl.
Castopulence Software <http://www.castopulence.org/> <bamccaig [at] castopulence=
..org>

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

At 13:00 -0500 04/02/2011, Uri Guttman wrote:

> HP> Yet they seem to be carefully avoided. That is what I nearly always
> HP> use. Is there some reason to avoid `//' as delimiters?

[ I really object to the backtick being used instead of an opening
quote mark. The only possiblt excuse for it is if plain text needs
eventually to be converted quickly to text containing curly quotes. ]

>
>no. you should // in most cases. you should change to alternate
>delimiters (for all delimited string like things) when the default
>delimiter is in the string itself...

I think it's misleading, and certainly inaccurate, to say you
_should_ use the solidus (the correct name for the character you
colloquially call a slash) in preference to any other delimiter in
matches and substitutions. I personally almost always use the tilde
as in m~x~, s~x~y, qq~string~, not only because it rarely occurs in
the patterns or the strings but also because I find it less likely to
be confusing. Others use different delimiters with just as much
right or reason. As you yourself say the solidus can become very
confusing as a delimiter because not only the solidus itself within a
pattern needs to be escaped with a reverse solidus but so may other
characters, with the risk of an unreadable string of leaning
toothpicks.

In brief people are free to use what they like. TMTOWTDI.

JD


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "JD" == John Delacour <johndelacour [at] gmail.com> writes:

JD> At 13:00 -0500 04/02/2011, Uri Guttman wrote:
HP> Yet they seem to be carefully avoided. That is what I nearly always
HP> use. Is there some reason to avoid `//' as delimiters?

JD> [ I really object to the backtick being used instead of an opening
JD> quote mark. The only possiblt excuse for it is if plain text needs
JD> eventually to be converted quickly to text containing curly quotes. ]

>>
>> no. you should // in most cases. you should change to alternate
>> delimiters (for all delimited string like things) when the default
>> delimiter is in the string itself...

JD> I think it's misleading, and certainly inaccurate, to say you _should_
JD> use the solidus (the correct name for the character you colloquially
JD> call a slash) in preference to any other delimiter in matches and
JD> substitutions. I personally almost always use the tilde as in m~x~,
JD> s~x~y, qq~string~, not only because it rarely occurs in the patterns
JD> or the strings but also because I find it less likely to be confusing.
JD> Others use different delimiters with just as much right or reason. As
JD> you yourself say the solidus can become very confusing as a delimiter
JD> because not only the solidus itself within a pattern needs to be
JD> escaped with a reverse solidus but so may other characters, with the
JD> risk of an unreadable string of leaning toothpicks.

it isn't misleading. you use default delimiters because they are the
ones you look for normally. using alternate delims tells the READER (not
yourself), that there is likely to be a standard delimiter inside the
string so look for it.

JD> In brief people are free to use what they like. TMTOWTDI.

taking your idea to the max, why not write with single letter var names
all the time? not all ways are good ways. just because you can do odd
things legally doesn't make it good code.

here are some coding rules to think about:

code is for people, not computers.
code is for OTHER people, not yourself.

you write code so other people can understand your intentions. if you
mislead them with alternate delimiters when they are not needed, they
will waste time looking for the normal delims in the string. therefor
you are telling the reader misinformation. that is not cool coding no
matter what you may think is legal or nice.

this comes from 35 years of coding and 18 years of perl. it isn't
something i just came up with last week and it is also a common convention
thing in perl so it is best to stick with that style. there are plenty
of conventions in perl coding and using // for regexes without / inside
is normal and expected.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-02-04 02:22 PM, Uri Guttman wrote:
> this comes from 35 years of coding and 18 years of perl. it isn't
> something i just came up with last week and it is also a common convention
> thing in perl so it is best to stick with that style. there are plenty
> of conventions in perl coding and using // for regexes without / inside
> is normal and expected.
>

I use curly braces: m{ pattern }msx

Also, I put things that are code inside back ticks because in *NIX they
mean execute.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

>>>>> "SHC" == Shawn H Corey <shawnhcorey [at] gmail.com> writes:

SHC> On 11-02-04 02:22 PM, Uri Guttman wrote:
>> this comes from 35 years of coding and 18 years of perl. it isn't
>> something i just came up with last week and it is also a common convention
>> thing in perl so it is best to stick with that style. there are plenty
>> of conventions in perl coding and using // for regexes without / inside
>> is normal and expected.
>>

SHC> I use curly braces: m{ pattern }msx

i use them when i need to, otherwise i stick with the standard // as
that is what is expected for regexes.

SHC> Also, I put things that are code inside back ticks because in *NIX
SHC> they mean execute.

and in awk and sed which are some of the major influences in perl, // is
the only regex delimiter. so there is plenty of history to using
them. perl added general flexibility to all delimiter but the style rule
is to use the standard one unless you have a reason to otherwise. don't
mislead the code reader. and don't code in your own peculiar style cause
you like it. you code for others to read so make your code readable. it
is the professional thing to do. i hope the goal of most of the list
members is to be a professional coder and this is a good set of rules to
learn.

another point i have to say is that i review perl code for my
perlhunter.com business. i see dozens of coding styles and i downgrade
those with pecularities like always using alternate delims when not
needed. those with better styles and who are open to feedback have a
better chance of my placing them in a perl job.

uri

--
Uri Guttman ------ uri [at] stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/