Home > Archive > Unix Programming > June 2007 > How to check for stuff like '|'
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
How to check for stuff like '|'
|
|
| K-mart Cashier 2007-06-25, 8:06 am |
| Given the following:
#include <stdio.h>
#include <utmp.h>
#include <stdlib.h>
#include <string.h>
#define LOG "/var/run/utmp"
static void check_name(char *who)
{
struct utmp log;
FILE *fp = fopen(LOG,"r");
if(fp != NULL) {
while(fread(&log,sizeof log,1,fp) == 1) {
if((strcmp(log.ut_user,who)) == 0){
printf("found name\n");
return;
}
else {
continue;
}
}
}
else {
perror(LOG);
}
}
int main(int argc, char *argv[])
{
if (argc != 2) {
fprintf(stderr, "Invalid input\n");
exit(EXIT_FAILURE);
}
check_name(argv[1]);
exit(EXIT_SUCCESS);
}
When I go like something like the following, it's fine
[cdalten@localhost ~]$ ./nameit cdalten
found name
However, when i ./nameit |, I get the '>'
[cdalten@localhost ~]$ ./nameit |
>
I thought if I checked argv[1] against the ut_user field in utmp, it
would have prevented something like this. Apparently it didn't Any
ideas how to handle stuff like '|' ?
Chad
| |
| Barry Margolin 2007-06-25, 8:06 am |
| In article <1182734541.507883.311310@m37g2000prh.googlegroups.com>,
K-mart Cashier <cdalten@gmail.com> wrote:
> When I go like something like the following, it's fine
> [cdalten@localhost ~]$ ./nameit cdalten
> found name
>
> However, when i ./nameit |, I get the '>'
> [cdalten@localhost ~]$ ./nameit |
>
> I thought if I checked argv[1] against the ut_user field in utmp, it
> would have prevented something like this. Apparently it didn't Any
> ideas how to handle stuff like '|' ?
| is a shell metacharacter, used to indicate that you're piping the
output of one command to another. It's not passed to the programs you
run unless you quote or escape it. When you get that ">" prompt, your
program hasn't even been started yet. The shell is still waiting for
you to finish typing the rest of the command line -- the command that
you want the output piped to.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Matthias Buelow 2007-06-25, 7:13 pm |
| K-mart Cashier wrote:
> else {
> continue;
> }
Oh, and please don't put {} around single statements, that's a nasty,
nasty Java habit that hurts the eye. Thanks.
| |
| Måns Rullgård 2007-06-25, 7:13 pm |
| Matthias Buelow <mkb@incubus.de> writes:
> K-mart Cashier wrote:
>
>
> Oh, and please don't put {} around single statements, that's a nasty,
> nasty Java habit that hurts the eye. Thanks.
It has nothing to do with Java, which has exactly the same syntax as C
in these matters. It's merely a matter of style.
That said, Java is a nasty thing that indeed does hurt the eyes.
--
Måns Rullgård
mans@mansr.com
| |
| Matthias Buelow 2007-06-25, 7:13 pm |
| Måns Rullgård wrote:
> It has nothing to do with Java, which has exactly the same syntax as C
> in these matters. It's merely a matter of style.
Yes but afaik Sun's styleguide recommends this (perhaps they think the
average Java programmer can't be expected to understand the difference
between a single expression or statement and a block of them. Which
probably isn't too far from the truth.)
| |
| Barry Margolin 2007-06-25, 10:07 pm |
| In article <5eaqhkF372bakU1@mid.dfncis.de>,
Matthias Buelow <mkb@incubus.de> wrote:
> Måns Rullgård wrote:
>
>
> Yes but afaik Sun's styleguide recommends this (perhaps they think the
> average Java programmer can't be expected to understand the difference
> between a single expression or statement and a block of them. Which
> probably isn't too far from the truth.)
It's a proactive way to prevent bugs when you add a second statement to
the branch and forget to add the surrounding braces.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Logan Shaw 2007-06-26, 8:05 am |
| Barry Margolin wrote:
> It's a proactive way to prevent bugs when you add a second statement to
> the branch and forget to add the surrounding braces.
It's also more consistent.
And for what it's worth, if the reason people hate 'em is that this:
if (foo()) {
thingA();
}
takes up more vertical space than this:
if (foo()) thingA();
then please keep in mind that there is no physical law preventing you
from placing braces on the same line, as in:
if (foo()) { thingA(); }
One might even argue that gives your eye an additional cue that helps
it more easily recognize the structure. At least, I'd argue that.
- Logan
| |
| Jason Curl 2007-06-27, 8:06 am |
| Matthias Buelow wrote:
> K-mart Cashier wrote:
>
>
> Oh, and please don't put {} around single statements, that's a nasty,
> nasty Java habit that hurts the eye. Thanks.
I think that's quatsch. The braces help to define program flow. What about :
if (A)
if (B)
foo()
else
bar()
or is it really:
if (A)
if (B)
foo();
else
bar();
By mandating braces everywhere it enforces a style that makes it more
difficult to insert these kind of logic errors. Most undergrads don't
know and tbh I never really cared as I always used braces.
And I've never programmed in Java, C++ and currently don't plan to. Only
C, mostly for non-GUI systems. So I don't know why you think it's Java only.
| |
| Rainer Weikusat 2007-06-27, 8:06 am |
| Jason Curl <j_dot_curl@motorola.com> writes:
> Matthias Buelow wrote:
>
> I think that's quatsch. The braces help to define program flow. What about :
>
> if (A)
> if (B)
> foo()
> else
> bar()
>
> or is it really:
>
> if (A)
> if (B)
> foo();
> else
> bar();
>
> By mandating braces everywhere it enforces a style that makes it more
> difficult to insert these kind of logic errors.
For C, the last else always refers to the last if and assuming
otherwise is not 'a logic error' but 'wrong usage of a tool'.
| |
| Logan Shaw 2007-06-28, 4:15 am |
| Jason Curl wrote:
> Matthias Buelow wrote:
[color=darkred]
> And I've never programmed in Java, C++ and currently don't plan to. Only
> C, mostly for non-GUI systems. So I don't know why you think it's Java
> only.
Indeed. It is the *only* option in Perl.
That is, this is legal Perl code:
if ($x > 7) { $x = 0; }
but this is NOT legal Perl code:
if ($x > 7) $x = 0;
After downloading some old versions of Perl from
http://history.perl.org/PerlTimeline.html , it would appear this has
been the case since Perl 1.0, released in late 1987.
Now, Larry Wall has some strange and unique ideas about language syntax,
so it's possible he invented the idea that if-statements should contain
blocks and never single statements. But it's also possible he picked
up the style of always using braces before creating Perl and he liked
the style so much he decided to codify it in Perl.
- Logan
| |
| John W. Krahn 2007-06-28, 4:15 am |
| Logan Shaw wrote:
> Jason Curl wrote:
>
>
>
> Indeed. It is the *only* option in Perl.
>
> That is, this is legal Perl code:
>
> if ($x > 7) { $x = 0; }
>
> but this is NOT legal Perl code:
>
> if ($x > 7) $x = 0;
But of course in Perl you could do it like this:
$x = 0 if $x > 7;
TMTOWTDI :-)
John
--
Perl isn't a toolbox, but a small machine shop where you
can special-order certain sorts of tools at low cost and
in short order. -- Larry Wall
| |
|
|
| Logan Shaw 2007-06-29, 4:16 am |
| John W. Krahn wrote:
> Logan Shaw wrote:
[color=darkred]
> But of course in Perl you could do it like this:
>
> $x = 0 if $x > 7;
Well yeah, or this:
($x > 7) && ($x = 0);
Or this:
($x > 7) ? ($x = 0) : undef;
Or assuming $x is an integer, this:
do { my $y = $x - 8; $y =~ s/^[^-]/$x = 0;/e; };
I guess what I should have said is that as far as convention if-statements
go, using braces is the only option in Perl... :-)
- Logan
|
|
|
|
|