new commands written in perl

W

wana

I made up a new Linux command, but I don't know if it already existed.

I named my command 'into'. It just appends a string to a file from
the command line. You can use it if you need to write down a phone
number or a quick note and you don't want to go into vi.

usage: into [file] string

Here's the code:

#! /usr/bin/perl -w
# This script allows a quick note to be saved to file
use strict;
my ($len,$string,$file);
$len = scalar @ARGV;

if (($len > 2) || ($len < 1) || ($ARGV[0] eq "--help"))
{
print <<end_of_line
Usage: into [file] string
I recommend using 'single quotes' around string if more than one word.
Will create file with string or append string to file.
If no file specified, string is appended to ~/.into.
end_of_line
}
else
{
if ($len == 1)
{
$file = "$ENV{'HOME'}/.into";
$string = $ARGV[0];
}
else
{
$file = $ARGV[0];
$string = $ARGV[1];
}
open OUT, ">>$file";
print OUT "$string\n";
close OUT;
}
exit(0);
 
E

Eric Schwartz

I named my command 'into'. It just appends a string to a file from
the command line.

You mean, like

$ echo "some quick note" >> file

or

$ cat >>file
some multi-line
text
^D

?

-=Eric
 
R

Robert Gamble

I made up a new Linux command, but I don't know if it already existed.

I named my command 'into'. It just appends a string to a file from
the command line. You can use it if you need to write down a phone
number or a quick note and you don't want to go into vi.

usage: into [file] string

It already exists, it's called "echo string >> file"

Rob Gamble
 
E

Eric Schwartz

#! /usr/bin/perl -w

Don't use -w; 'use warnings;' instead.
# This script allows a quick note to be saved to file
use strict;
my ($len,$string,$file);

Don't declare these so early; wait until you need them. If there's an
error, or the user requests help, you don't need $string or $file at
all. (You don't need $len either, but more about that in a bit.)
$len = scalar @ARGV;
if (($len > 2) || ($len < 1) || ($ARGV[0] eq "--help"))
{

This is a poorly named variable (len implies 'length', usually of
strings, not of arguments). Also, the 'scalar' is unnecessary; the
scalar variable on the left-hand side of the assignment puts it into
scalar context already.

if (@ARGV > 2 or @ARGV < 1 or $ARGV[0] eq '--help')
{

Notice how I used single quotes there. Some people will tell you it's
mandatory; I wouldn't go that far. But as a general principle, I do
think it's helpful to only use double-quotes when you expect to
interpolate a variable in your string.
print <<end_of_line

BTW, this is a bit misleading; it's not the end of the line that
you're stopping at, it's the end of the help text. And most people
around here tend to use all caps for the end-of-heredoc marker.

Also, you're missing a semicolon after the print statement; this isn't
strictly required, since it's the only statement in a block, but what
if you decided to exit afterwards, and put an 'exit 1' at the end of
the block?

This should look like:

print <<EOHELP;
Usage: into [file] string
I recommend using 'single quotes' around string if more than one word.
Will create file with string or append string to file.
If no file specified, string is appended to ~/.into.
end_of_line
}

This is a stylistic thing; I would have put an exit at the end of the
if statement, and not bothered putting the else inside an explicit
else block. To me, this clearly points out that the bits that follow
are the 'normal' operation of the program, and the 'if' statement is
just for exception handling.

Also, I just noticed-- fix your indentation, or lack thereof.
Indentation is a clue to your program's structure. I like three
spaces inside a block, some people like four, others prefer 8. I
don't care what you use, but use *some*, mmmkay?

Remember, whitespace is NOT endangered! Use it!
if ($len == 1)
{
$file = "$ENV{'HOME'}/.into";
$string = $ARGV[0];
}
else
{
$file = $ARGV[0];
$string = $ARGV[1];
}

Indent!

At this point, I've forgotten what $len even means; I have to go look
for it. This wouldn't normally happen for such a small program, but
I've written quite a few comments already, so my brain got full. If
you swapped your command-line around so that it was

into string [file]

Your code could look like:

my ($string, $filename) = @ARGV;
$filename = "$ENV{HOME}/.into" unless $filename;

Even as it is, you could write this whole silly parsing block as

my ($filename, $string) = @ARGV;
if (!defined $string) { # only one argument passed in
$string = $filename;
$filename = "$ENV{HOME}/.into";
}
open OUT, ">>$file";

Always always always ALWAYS check the return from an open()! I cannot
emphasize this strongly enough. You probably ought to check on
close() as well-- in fact, if you're going to be anal, you should
check the results of every function that references a system call.
But you wouldn't believe the sheer number of problems we have
uncovered in this newsgroup by virtue of people simply rewriting that
as

open OUT, ">>$file" or die "Couldn't open $file: $!";

Just Do It(tm).
print OUT "$string\n";
close OUT;

You can also do this with lexical filehandles, and the three-arg form
of open() (which I think it the cat's pyjamas):

open my $file, '>>', $filename or die "Couldn't open $filename: $!";
print $file $string,"\n";
close $file or die "Error closing $filename: $!";
}
exit(0);

Fine, but unnecessary.

-=Eric
 
Z

Zebee Johnstone

In comp.lang.perl.misc on Tue, 21 Sep 2004 12:34:40 -0600
Eric Schwartz said:
Don't use -w; 'use warnings;' instead.
Why?

Notice how I used single quotes there. Some people will tell you it's
mandatory; I wouldn't go that far. But as a general principle, I do
think it's helpful to only use double-quotes when you expect to
interpolate a variable in your string.

Why? The main reason I've found is that copying and pasting into a
print statement is made easier.



Zebee
 
P

Paul Lalli

Zebee Johnstone said:
In comp.lang.perl.misc on Tue, 21 Sep 2004 12:34:40 -0600


Why?

Because -w is a global switch. Once you use it, you can't refine it.

use warnings; on the other hand, is a lexical pragma. You can turn it
off for certain sections of the code if you need to. For example:

use warnings;
print "Here I am!\n";
my $str = "23foo";
my $num;
{
no warnings 'numeric';
$num = $str + 3;
}

In that block, you're effectively saying you *know* what you're about to
do is going to cause a "$str is not numeric" warning, and you're okay
with that. There are times when you're coding that you might want to do
something that would generate a warning. This way, you can shut off
that warning.
Why? The main reason I've found is that copying and pasting into a
print statement is made easier.

There are three schools of thought on this.

One school holds that you should always use single quotes, unless you
need to do interpolation. That way, when looking over your code, you
have a clear signal that the string you're looking at will contain a
variable you might need to do something with.
The second holds that you should aways use double quotes, unless you
very specifically do *not* want interpolation. That way, when looking
over your code, you're given a clear signal that the string you're
looking at does not contain any variables.
The third school of thought says "whatever" and does whatever it feels
like at any given moment.

Paul Lalli
 
E

Eric Schwartz

Zebee Johnstone said:
In comp.lang.perl.misc on Tue, 21 Sep 2004 12:34:40 -0600


Why?

The warnings pragma catches slightly more things, I believe, but the
big trick is that you can turn off certain warnings selectively; with
-w you can clear $^W to turn them all off, or set it again to turn
them all back on, but that's it.
Why? The main reason I've found is that copying and pasting into a
print statement is made easier.

If you see 'string', you know there can't be any interpolation inside
it. If you see "string", there can be. If you always get in the
habit of using 'string' unless you specifically want interpolation,
then it's just one more small clue that people reading your code can
use to help decipher it.

This follows from the basic principle that Writing Code Is Easy;
Reading Code is Hard (I think I stole that from Damian Conway; I'm not
sure). If you do everything you can to make reading your code easier,
it'll make your code more maintainable and useful. Sure, quotes are
not THAT big a deal, which is why I'm not an absolutist about them.
But they can provide some help you didn't have before.

-=Eric
 
U

Uri Guttman

A> No, no, no. As a general principle, use single quotes if your string
A> contains (or may contain in the future) quotes, or a dollar or @ sign
A> you don't want to interpolate. Otherwise, use double quotes.

A> You'll notice that means you will have to change quotes far less
A> often than if your default is single quotes.

that is debatable. your strings may morph less that way but mine don't
morph too often and i don't mind the change since i do it for the
maintainer.

A> Besides, using double quotes make feel C programmers more at ease.

and single quotes will make the shell programmers more at ease. :)

uri
 
G

Gregory Toomey

Abigail said:
Of course, the shell has much
cooler strings than Perl has.

Abigail

Why do you say that. I don't know where I'd be without
" ...@{[subcall()]} ..." (or japhs for that matter).

gtoomey
 
T

Ted Zlatanov

You mean, like

$ echo "some quick note" >> file

or

$ cat >>file
some multi-line
text
^D

?

No, it's NOT the same thing. His program doesn't use the shell. It
may be trivial, but it's not useless.

In addition, note the default behavior is to append to ~/.into when no
file name is given.

Ted
 
R

Robert Gamble

No, it's NOT the same thing. His program doesn't use the shell. It
may be trivial, but it's not useless.

Of course his program uses the shell, what do you think is calling the
program and passing it the parameters? This could be done from another
program without the shell, but in the examples provided, the shell plays
as much a role as it does in the above examples.

It may not be totally useless but the point is that this functionality
already exists with trivial shell operations which addresses the question
the OP asked.
In addition, note the default behavior is to append to ~/.into when no
file name is given.

Maybe there should be a complementing utility called "outof" that will
read from ~/.into by default to justify using it over cat...

Rob Gamble
 
E

Eric Schwartz

Abigail said:
No, no, no. As a general principle, use single quotes if your string
contains (or may contain in the future) quotes, or a dollar or @ sign
you don't want to interpolate. Otherwise, use double quotes.

As I said, opinions differ, and I don't particularly care either way--
If I worked where the local style was different, I would adjust easily.
You'll notice that means you will have to change quotes far less often
than if your default is single quotes.

It all depends on what you're saying. My style says, "I'm calling
your attention to when I want to interpolate something," yours calls
attention to when you DON'T want to interpolate. That's fine, too.
Besides, using double quotes make feel C programmers more at ease.

It's been quite a while since that was a big problem for me. :)

-=Eric
 
E

Eric Schwartz

Abigail said:
No. Not at all. My style doesn't "call attention". It minimizes work.

We're disputing semantics at this point, which is rarely productive.
I use quotes for what they are, quotes. It doesn't have a meta meaning.
They are there for the parser and nothing else.

But someone reading your code is going to likely come to the
conclusion that "" is the default, so when they hit '', they may
examine it more closely. That's all I'm saying.

-=Eric
 
A

Anno Siegel

Robert Gamble said:
Of course his program uses the shell, what do you think is calling the
program and passing it the parameters?

Cron? Perl? find? xargs? Thousands of programs can start other
programs, not only shells.

Anno
 
A

Anno Siegel

Robert Gamble said:
Of course his program uses the shell, what do you think is calling the
program and passing it the parameters?

cron? perl? find? xargs? Thousands of programs can start other
programs, not only shells.

Anno
 
T

Ted Zlatanov

Of course his program uses the shell, what do you think is calling the
program and passing it the parameters?

Any other program can do it - the shell is a common choice, but not
the only one.
It may not be totally useless but the point is that this functionality
already exists with trivial shell operations which addresses the question
the OP asked.

Sometimes the shell is not a good choice for trivial operations
(e.g. `cat' is a pretty redundant program when you use a shell).

Hell, we don't need 90% of Unix commands because Perl can emulate them
according to your argument.
Maybe there should be a complementing utility called "outof" that will
read from ~/.into by default to justify using it over cat...

I like the way you glossed over this big difference from the `cat'
approach with a quick "if this goes on..." response. Good work.

Ted
 
R

Robert Gamble

Any other program can do it - the shell is a common choice, but not
the only one.

You are the second person so far to selectively quote what I said about
the shell running the program to misrepresent my statements. Why don't
you try reading the sentence immediately following the one you quoted
where I address the same thing you comment on?
Sometimes the shell is not a good choice for trivial operations (e.g.
`cat' is a pretty redundant program when you use a shell).

Hell, we don't need 90% of Unix commands because Perl can emulate them
according to your argument.

Don't see how you come up with this at all...
I like the way you glossed over this big difference from the `cat'
approach with a quick "if this goes on..." response. Good work.

I was being sarcastic although I do not quite understand what you are
trying to say here either.
 
E

Eric Schwartz

Abigail said:
Eric Schwartz ([email protected]) wrote on MMMMXLI September MCMXCIII in
<URL:,, But someone reading your code is going to likely come to the
,, conclusion that "" is the default, so when they hit '', they may
,, examine it more closely. That's all I'm saying.


Do you do that? If you see a piece of code, are you going to inspect
the quotes, make tallies to see what is the default, and when you
encounter something that isn't the default, you're going to inspect
it more closely?

Not anymore, but when I was learning Perl, I did something much like
it. I imagine I actually still do it, albeit unconsciously. Much as
when I learned to read English, I sounded out every letter until I was
fluent, at which point that all happened in the background, so to
speak.

-=Eric
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,755
Messages
2,569,535
Members
45,007
Latest member
obedient dusk

Latest Threads

Top