Newbie question

2007-09-13 Thread chitti

Can anyone tell me how to find identify all suid and sgid programs, display
their name, permission, time stapms and size, et. al in format similar to
the output of shell command "ls" in the following directory
/usr/bin and /usr/ucb
many thanks

-- 
View this message in context: 
http://www.nabble.com/Newbie-question-tf4437434.html#a12660256
Sent from the Gnu - Bash mailing list archive at Nabble.com.





Re: bash scripting help

2007-09-13 Thread chitti

thank you very much

Stephane CHAZELAS-3 wrote:
> 
> 2007-09-12, 10:00(-07), chitti:
>>
>> I need to seperate the UDP and TCP ports from the /etc/services files.
>> any pointers or help on scripting this in bash would be helpful
>> thanks
> 
> awk '
>   NF == 0 || $1 ~ /^#/ {next}
>   $2 ~ /\/tcp$/ {print > "services.tcp"; next}
>   $2 ~ /\/udp$/ {print > "services.udp"; next}
>   {print > "services.other"}' < /etc/services
> 
> 
> -- 
> Stéphane
> 
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/bash-scripting-help-tf4430729.html#a12660260
Sent from the Gnu - Bash mailing list archive at Nabble.com.





Re: Newbie question

2007-09-13 Thread Matthew Woehlke

chitti wrote:

Can anyone tell me how to find identify all suid and sgid programs, display
their name, permission, time stapms and size, et. al in format similar to
the output of shell command "ls" in the following directory
/usr/bin and /usr/ucb
many thanks


You're on the wrong forum, as this question has nothing to do with bash. 
To help get you started anyway, try 'man find'.


--
Matthew
Hey! Where's the witty punchline?
(with apologies to Hostess)





Re: TAB strips wildcards

2007-09-13 Thread Chet Ramey
[EMAIL PROTECTED] wrote:
> Here is a true case of what happens when you hit TAB with a wildcard:
> $ shar /tmp/logs/*/*/*
> access.log  access.log
> $ shar /tmp/logs/
> Yes, it strips the wildcards!

Yes, it does.  Readline completion replaces the word on which completion
is attempted with the longest common prefix of the matches.  The
show-all-if-ambiguous option doesn't change that behavior; it just causes
the possible completions to be listed instead of ringing the bell.

I will take a look and see what can be done, but this behavior is fairly
basic.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/




Re: bash 3.2.9, constructing array references with indirect expansion

2007-09-13 Thread Chet Ramey
Misfortunado Farmbuyer wrote:
> I've been staring at Chet's message in
> http://www.mail-archive.com/bug-bash@gnu.org/msg01545.html
> for a while, and now I understand why my own script (doing something
> similar) was not originally working.  What I can't quite figure is what
> to change.
> 
> I'm source'ing a series of assignments of the form
>   DIRS_name1=(/foo /bar /baz)
>   DIRS_name2=(/qux /quux)
>   
> and earlier in the file, a list of the arbitrary 'name's are assigned.
> Running through the list of 'name's and composing the corresponding array
> variable name is no trouble, but I can't manage to indirect through to the
> entire array.  Like the person I linked to above, I keep ending up with only
> the first member of the array:

You have to remember that referencing an array variable without using
[EMAIL PROTECTED] will always return the first element of the array.  Indirect
variable expansion cannot be coerced to do otherwise.

You can always use `eval' to force the sort of double expansion you
want.  Just remember to quote everything whose evaluation you want
deferred:

DIRS_name1=( /foo /bar /baz )
DIRS_name2=( /qux /quux )

name=${1:-name1}

v=DIRS_$name

eval a='( "${'$v'[EMAIL PROTECTED]" )'

echo [EMAIL PROTECTED]

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/




Re: time builtin handles backgrounding poorly

2007-09-13 Thread Chet Ramey
Jack Lloyd wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: x86_64
> OS: linux-gnu
> Compiler: x86_64-redhat-linux-gcc
> Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' 
> -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' 
> -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' 
> -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include -I./lib  -D_GNU_SOURCE  -O2 -g 
> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector 
> --param=ssp-buffer-size=4 -m64 -mtune=generic
> uname output: Linux wks9 2.6.15-1.2054_FC5 #1 SMP Tue Mar 14 15:48:20 EST 
> 2006 x86_64 x86_64 x86_64 GNU/Linux
> Machine Type: x86_64-redhat-linux-gnu
> 
> Bash Version: 3.1
> Patch Level: 7
> Release Status: release
> 
> Description:
> 
> The time builtin seems to be confused if something is
> backgrounded, and prints immediately the time rather than
> waiting for the job to complete. I found this very unexpected.

`time' is not a builtin; it is a shell reserved word that causes timing
information to be printed when `waitpid' returns.  It's a synchronous
operation that doesn't interact as you'd like with job control.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/




Re: Process Substitution backgrounds the command list?

2007-09-13 Thread Chet Ramey
Bob Proulx wrote:
> I am confused by the order of operations of this following:
> 
>   $ { echo hello world | tee >(md5sum 1>&2) ;} ; echo goodbye
>   hello world
>   goodbye
>   $ 6f5902ac237024bdd0c176cb93063dc4  -
> 
> Shouldn't bash wait for the subprocess finish before the next command
> is invoked?  I did not expect the >(list) to continue to run in the
> background after the entire pipeline returned.
> 
> Is there a way to explicitly wait for that process in order to
> synchronize subsequent operations?

No, there's no way to wait for it.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
   Live Strong.  No day but today.
Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/