i want to frame a grep command which is successful if and only if the
line contains ONLY alphabets and spaces no special characters and
digits are allowed

"Rishi" <postrishi@gmail.com> wrote in message
> i want to frame a grep command which is successful if and only if the
> line contains ONLY alphabets and spaces no special characters and
> digits are allowed
>
Try comp.lang.perl.

Regular expressions are an integeral part of Perl. In C you have to get the 
library yourself, and syntax differs.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm McLean wrote:
> 
> "Rishi" <postrishi@gmail.com> wrote in message
>> i want to frame a grep command which is successful if and only if the
>> line contains ONLY alphabets and spaces no special characters and
>> digits are allowed
>>
> Try comp.lang.perl.

Actually comp.unix.programmer might be more appropriate.

On Jan 23, 10:02 am, Rishi <postri...@gmail.com> wrote:
> i want to frame a grep command which is successful if and only if the
> line contains ONLY alphabets and spaces no special characters and
> digits are allowed

Are you asking how to do this in C?
strspn(line, "ABCD...Zabcd...z \t\n") == strlen(line)
does about what you want, replacing ... with the obvious
intervening ... characters filled in.  And perhaps spaces defined
differently.

If you want regexps, there are a large number of such libraries,
search them out and find documentation for them.  And if you really
mean grep, why did you ask here?

-David

In article <0cbb8603-661d-4533-9f29-1eb2321b2703@e4g2000hsg.googlegroups.com>,
Rishi  <postrishi@gmail.com> wrote:

>i want to frame a grep command which is successful if and only if the
>line contains ONLY alphabets and spaces no special characters and
>digits are allowed

You haven't defined "alphabets". Do you need to match the
German Eszett along with the (rather more common) Sanskrit ghnya ?


-- 
  "Is there any thing whereof it may be said, See, this is new? It hath
  been already of old time, which was before us."    -- Ecclesiastes

Mark Bluemel <mark_bluemel@pobox.com> writes:
> Malcolm McLean wrote:
>> "Rishi" <postrishi@gmail.com> wrote in message
>>> i want to frame a grep command which is successful if and only if the
>>> line contains ONLY alphabets and spaces no special characters and
>>> digits are allowed
>>>
>> Try comp.lang.perl.
>
> Actually comp.unix.programmer might be more appropriate.

If the original poster is really looking for a grep *command*,
comp.unix.shell is probably the right place.

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

"Walter Roberson" <roberson@ibd.nrc-cnrc.gc.ca> wrote in message
> In article 
> <0cbb8603-661d-4533-9f29-1eb2321b2703@e4g2000hsg.googlegroups.com>,
> Rishi  <postrishi@gmail.com> wrote:
>
>>i want to frame a grep command which is successful if and only if the
>>line contains ONLY alphabets and spaces no special characters and
>>digits are allowed
>
> You haven't defined "alphabets". Do you need to match the
> German Eszett along with the (rather more common) Sanskrit ghnya ?
>
The standard can fix that

int testtext(char *str)
{
  while(*str)
  {
     if(!isalpha( (unsigned int) *str) && !isspace( (unsigned int) *str))
       return 0;
    str++;
  }
  return 1;
}

To the OP, sorry about the horrid casts to int. They are needed to fix up 
problems in the is.... functions when passed negative chars.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm McLean wrote:

> int testtext(char *str)
> {
>   while(*str)
>   {
>      if(!isalpha( (unsigned int) *str) && !isspace( (unsigned int) *str))
>        return 0;
>     str++;
>   }
>   return 1;
> }
> 
> To the OP, sorry about the horrid casts to int. They are needed to fix up 
> problems in the is.... functions when passed negative chars.
Why not unsigned char?
-- 
Army1987 (Replace "NOSPAM" with "email")

Malcolm McLean wrote:
> 
.... snip ...
>
> The standard can fix that
> 
> int testtext(char *str) {
>   while(*str) {
>      if(!isalpha( (unsigned int) *str) && !isspace( (unsigned int) *str))
>        return 0;
>     str++;
>   }
>   return 1;
> }
> 
> To the OP, sorry about the horrid casts to int. They are needed
> to fix up problems in the is.... functions when passed negative
> chars.

Try simply receiving str as an unsigned char*

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

"CBFalconer" <cbfalconer@yahoo.com> wrote in message
> Malcolm McLean wrote:
>>
> ... snip ...
>>
>> The standard can fix that
>>
>> int testtext(char *str) {
>>   while(*str) {
>>      if(!isalpha( (unsigned int) *str) && !isspace( (unsigned int) *str))
>>        return 0;
>>     str++;
>>   }
>>   return 1;
>> }
>>
>> To the OP, sorry about the horrid casts to int. They are needed
>> to fix up problems in the is.... functions when passed negative
>> chars.
>
> Try simply receiving str as an unsigned char*
>
That would imply that str is in fact a buffer full of bytes, rather than a 
human-readable string.
The is.... macros don't work on chars. Which is a silly quirk. But the time 
to undo it is at the call.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm wrote:
)> Try simply receiving str as an unsigned char*
)>
) That would imply that str is in fact a buffer full of bytes, rather than a 
) human-readable string.

Why does a human-readable string have to be 'char' and not 'unsigned char'?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

"Willem" <willem@stack.nl> wrote in message
> Malcolm wrote:
>
> Why does a human-readable string have to be 'char' and not 'unsigned
> char'?
>
Because "char" has been overworked. sizeof(char) is always one, so "char" 
and "byte" are synonyms. With hindsight, a pointless decision, but now we've 
got to live with it.
char means a human-readable character. It can have trap representations. 
Conventionally a list of chars will be terminated by a nul, and most library 
functions insist on that. Also an embedded string literal will be a char 
array.

unsigned char means a byte. Not infrequently, for instance in compression 
algorithms, you want to treat data as a list of bits or bytes.

Whilst conversions between char * and unsigned char * will generally result 
in no code being executed, you are playing fast and loose with the C type 
system by using them. They mean different things.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

Malcolm McLean wrote:
> "CBFalconer" <cbfalconer@yahoo.com> wrote in message
>> Malcolm McLean wrote:
>>>
>> ... snip ...
>>>
>>> The standard can fix that
>>>
>>> int testtext(char *str) {
>>>   while(*str) {
>>>      if(!isalpha( (unsigned int) *str) && !isspace( (unsigned int) *str))
>>>        return 0;
>>>     str++;
>>>   }
>>>   return 1;
>>> }
>>>
>>> To the OP, sorry about the horrid casts to int. They are needed
>>> to fix up problems in the is.... functions when passed negative
>>> chars.
>>
>> Try simply receiving str as an unsigned char*
>
> That would imply that str is in fact a buffer full of bytes,
> rather than a human-readable string.  The is.... macros don't work
> on chars. Which is a silly quirk. But the time to undo it is at
> the call.

But they will always be loaded as unsigned.  Just change the str
definition, and remove the ugly unnecessary casts.  While you're at
it, put a space after while and if, they are not functions.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.


-- 
Posted via a free Usenet account from http://www.teranews.com

Willem wrote:

> Malcolm wrote:
> )> Try simply receiving str as an unsigned char*
> )>
> ) That would imply that str is in fact a buffer full of bytes, rather than a 
> ) human-readable string.
> 
> Why does a human-readable string have to be 'char' and not 'unsigned char'?
I think he has a point, *(unsigned char *)charptr and (unsigned
char)*charptr are different if char is signed and doesn't use 2's
complement and charptr points to a negative char.

-- 
Army1987 (Replace "NOSPAM" with "email")

Army1987 wrote:
) I think he has a point, *(unsigned char *)charptr and (unsigned
) char)*charptr are different if char is signed and doesn't use 2's
) complement and charptr points to a negative char.

Yes, but if a string contains non-ASCII characters, i.e. characters with
the high bit set, then are those defined in a signed or in an unsigned
context ?


SaSW, Willem
-- 
Disclaimer: I am in no way responsible for any of the statements
            made in the above text. For all I know I might be
            drugged or something..
            No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

Army1987 wrote:
> I think he has a point, *(unsigned char *)charptr and (unsigned
> char)*charptr are different if char is signed and doesn't use 2's
> complement and charptr points to a negative char.

And I think that this has the interesting effect that `fputs(string,
stream);` and `fwrite(string, 1, strlen(string), stream);` could do
different things if string contains some negative chars and char is signed
with ones' complement or sign-and-magnitude.

For example, if string is
unsigned char string[2] = { 0xf0, 0 };
and char is 8-bits, sign and magnitude, the former will putc(-0x70,
stream), effectively writing 0x90 as putc converts its argument to
unsigned char, reducing it modulo 0x100, and the latter will putc(0xfo,
stream).

Or will they?
-- 
Army1987 (Replace "NOSPAM" with "email")

In article <slrnfph4hk.2hj9.willem@snail.stack.nl>, Willem 
<willem@stack.nl> writes
>Malcolm wrote:
>)> Try simply receiving str as an unsigned char*
>)>
>) That would imply that str is in fact a buffer full of bytes, rather than a
>) human-readable string.
>
>Why does a human-readable string have to be 'char' and not 'unsigned char'?

Because signed and unsigned char are integer types.
Plain char is a character type

It is implementation defined as to weather  the plain char is signed to 
unsigned in the implementation.

So for char you should always explicitly use signed or unsigned for data 
but plain char for Characters

MISRA-C for example defines
int8_t
uint8_t
char_t

to keep them separate

When you  typeddef to char_t  you should not what your specific 
implementation does. Signed or uinsigned



-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Chris Hills wrote:
> Willem <willem@stack.nl> writes
>>
.... snip ...
>>
>> Why does a human-readable string have to be 'char' and not
>> 'unsigned char'?
> 
> Because signed and unsigned char are integer types.
> Plain char is a character type
> 
> It is implementation defined as to weather the plain char is
> signed to unsigned in the implementation.

Not so.  Most of the characters, and especially the required C char
set, are required to be positive, and thus can be expressed in
unsigned chars.  This is why systems with 8 bit bytes using EBCDIC
have to define char as unsigned.  Unsigned char also covers the
complete range of the ASCII char set.

-- 
 [mail]: Chuck F (cbfalconer at maineline dot net) 
 [page]: <http://cbfalconer.home.att.net>
            Try the download section.



-- 
Posted via a free Usenet account from http://www.teranews.com

CBFalconer <cbfalconer@yahoo.com> writes:
> Chris Hills wrote:
>> Willem <willem@stack.nl> writes
>>>
> ... snip ...
>>>
>>> Why does a human-readable string have to be 'char' and not
>>> 'unsigned char'?
>> 
>> Because signed and unsigned char are integer types.
>> Plain char is a character type
>> 
>> It is implementation defined as to weather the plain char is
>> signed to unsigned in the implementation.
>
> Not so.  Most of the characters, and especially the required C char
> set, are required to be positive, and thus can be expressed in
> unsigned chars.  This is why systems with 8 bit bytes using EBCDIC
> have to define char as unsigned.  Unsigned char also covers the
> complete range of the ASCII char set.

It's clearly implementation-defined whether the the plain char type is
signed or unsigned, which I presume is what Chris meant.

-- 
Keith Thompson (The_Other_Keith) <kst-u@mib.org>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

In article <87fxwlijdl.fsf@kvetch.smov.org>, Keith Thompson 
<kst-u@mib.org> writes
>CBFalconer <cbfalconer@yahoo.com> writes:
>> Chris Hills wrote:
>>> Willem <willem@stack.nl> writes
>>>>
>> ... snip ...
>>>>
>>>> Why does a human-readable string have to be 'char' and not
>>>> 'unsigned char'?
>>>
>>> Because signed and unsigned char are integer types.
>>> Plain char is a character type
>>>
>>> It is implementation defined as to weather the plain char is
>>> signed to unsigned in the implementation.
>>
>> Not so.  Most of the characters, and especially the required C char
>> set, are required to be positive, and thus can be expressed in
>> unsigned chars.  This is why systems with 8 bit bytes using EBCDIC
>> have to define char as unsigned.  Unsigned char also covers the
>> complete range of the ASCII char set.
>
>It's clearly implementation-defined whether the the plain char type is
>signed or unsigned, which I presume is what Chris meant.
>

Yes..... I once did (many years ago) a survey into this point and whilst 
the majority went one way several others went the other way.

When string handling it is usually not important but for other 
manipulations it can cause problems.  So you do need to know what your 
implementation uses.  It can play havoc with portability
-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

"Chris Hills" <chris@phaedsys.org> wrote in message
>
> When string handling it is usually not important but for other 
> manipulations it can cause problems.  So you do need to know what your 
> implementation uses.  It can play havoc with portability
>
My crossword generator probably won't do non-English crosswords. Certainly 
not nicely. The letters have got to be written to html files.

-- 
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm