Re: Problem with reading file and executing other stuffs?
Hugh Sasse wrote: > > OK, if it is in fields, like /etc/passwd, then awk is probably more > suited to this problem than reading it directly with shell script. > > If it has some delimited keyword, but each line has variable structure, > then you'd be better using sed. > The files contain something like: aaa xxx xxx x x bbb xxx xxx xxx xxx xx xx ccc xx x x aaa, bbb, ccc are the known unique elements. No, they don't have a fixed size. And no, there's no delimited keyword except the first space after them. Those xxx are sequences of characters that can be anything, from numbers to letters and different length. The elements are known and unique, and I need to extract the whole line beginning with such elements. That's why I used the example of "database table". Is awk suitable? I know nothing about awk. Hugh Sasse wrote: > > Both of these operate linewise on their input, and can use regular > expressions and actions in braces to produce some textual response. > You can pass that response to `xargs -n 1` or something. > I'm not sure I understand since I know nothing about awk. But this could be postponed to a later time for discussion if adequate. Hugh Sasse wrote: > >> unique element that determines what should be done. Of course, I could >> go a >> grep on the file to find out the elements, but this would give a >> complexity >> of O(n^2). > > Not sure how you get the O(n^2) from that unless you don't know what > the unique elements are, but I still make that "one pass to read them > all, one pass to execute them" [with apologies to Tolkien :-)] >> >> I know that every line is processed only once, and the pointer to the >> current line will never go back. So I figure out that I could read every >> line in an array element and I could process line by line. This would >> give >> a O(n) which is much faster. > > Yes, agreed. Throw us a few example lines, fictionalised, then we may > be able to give you an example of an approach with greater simplicity. > Put it in a simple way, the pseudo algo of extracting lines is like this: n = number of lines in the file (which is also the number of elements to process) element = array(1 to n) of known elements for i = 1 to n use grep or whatever to extract a whole line beginning with element(i) //process the line end Here, grep has to parse the whole file to extract one line. In other words, if there're 3 elements, grep has to parse 3 lines for every element. Thus it has to parse 9 lines during the whole algo. Therefore, if there're n elements, grep has to parse n lines for n times. Thus O(n^2). Even if grep stops at the first occurence of the element, grep has to parse n/2 lines in average. So the time is proportional to n^2/2, so the complexity is still O(n^2). -- View this message in context: http://www.nabble.com/Problem-with-reading-file-and-executing-other-stuffs--tf4733602.html#a13706888 Sent from the Gnu - Bash mailing list archive at Nabble.com.
Re: Problem with reading file and executing other stuffs?
On Mon, 12 Nov 2007, Horinius wrote:
>
>
> Hugh Sasse wrote:
> >
> > OK, if it is in fields, like /etc/passwd, then awk is probably more
> > suited to this problem than reading it directly with shell script.
> >
> > If it has some delimited keyword, but each line has variable structure,
> > then you'd be better using sed.
> >
>
> The files contain something like:
> aaa xxx xxx x x
> bbb xxx xxx xxx xxx xx xx
> ccc xx x x
>
> aaa, bbb, ccc are the known unique elements. No, they don't have a fixed
> size. And no, there's no delimited keyword except the first space after
> them. Those xxx are sequences of characters that can be anything, from
> numbers to letters and different length.
>
> The elements are known and unique, and I need to extract the whole line
> beginning with such elements. That's why I used the example of "database
> table". Is awk suitable? I know nothing about awk.
#!/bin/bash
# Here is an example using gawk with its input in a here document.
gawk '/^aaa/ {print "got aaa" $0} \
/^bbb/ {print "got bbb"; \
print "$1 is" $1; \
print "$2 is" $2; \
print "$3 is" $3; \
} \
/^ccc/ {print "got ccc " NF " fields"}' <
>
> Hugh Sasse wrote:
> >
> > Both of these operate linewise on their input, and can use regular
> > expressions and actions in braces to produce some textual response.
> > You can pass that response to `xargs -n 1` or something.
> >
>
> I'm not sure I understand since I know nothing about awk. But this could be
> postponed to a later time for discussion if adequate.
As you can see from the above, it is easy to print stuff in awk.
That output is picked up for use as script by xargs. xargs reads
lines, and (possibly appends them to supplied argument lists and)
executes the commands.
>
>
> Hugh Sasse wrote:
> >
> > Yes, agreed. Throw us a few example lines, fictionalised, then we may
> > be able to give you an example of an approach with greater simplicity.
> >
>
> Put it in a simple way, the pseudo algo of extracting lines is like this:
> n = number of lines in the file (which is also the number of elements to
> process)
> element = array(1 to n) of known elements
> for i = 1 to n
>use grep or whatever to extract a whole line beginning with element(i)
>//process the line
> end
perfect for awk.
>
> Here, grep has to parse the whole file to extract one line. In other words,
> if there're 3 elements, grep has to parse 3 lines for every element. Thus
> it has to parse 9 lines during the whole algo. Therefore, if there're n
> elements, grep has to parse n lines for n times. Thus O(n^2).
Awk does it line by line, so it is O(n)
>
> Even if grep stops at the first occurence of the element, grep has to parse
> n/2 lines in average. So the time is proportional to n^2/2, so the
> complexity is still O(n^2).
OK.
HTH
Hugh
SIGTTOU handling
Hi: I'm having some trouble with bash -- it doesn't seem to be a problem with bash, but rather in my understanding of how job control works. This seemed like a pretty good place to start looking for the sort of help I need on this. At present, I'm writing what I call a terminal repeater. It allocates a unix socket and a pty. It forks and the parent process becomes a pretty typical server connection which monitors for connections to the unix socket and writes to the pty. When a write occurs to the pty, the parent process repeats that write to each of the connections to the unix socket. Using this method, the exact screen contents can be duplicated to a number of viewers. I had some difficulties getting job control working at first. I found that having the child process do a setpgrp() before forking to the bash instance made the error message about disabling job control go away. The problem for which I'm seeking help deals with the way bash handles the SIGTTOU signal. I can duplicate the problem by typing "less /etc/passwd &". When I do this under a normal bash process, I get: $ less /etc/passwd & [1] 28054 $ [1]+ Stopped less /etc/passwd $ When I launch this under my repeater, I get: $ less /etc/passwd & [1] 28473 $ [1]+ Stopped(SIGTTOU)less /etc/passwd $ Under a normal bash process, I can then foreground it and everything works the way it ought to. However, if I try to foreground it under the bash process running on top of my repeater, I get: $ fg less /etc/passwd [1]+ Stopped(SIGTTOU)less /etc/passwd $ My assumption is that I'm not setting up something correctly before running my execl to bash because I'm not seeing similar behavior in bash on either side. Can someone provide a hint to this end? My deepest thanks for your time and any advice you might be able to provide. -Phil
Re: SIGTTOU handling
On Sun, Nov 11, 2007 at 09:56:11PM -0800, [EMAIL PROTECTED] wrote: > Can someone provide a hint to this end? My deepest > thanks for your time and any advice you might be > able to provide. I get exactly that behaviour with a program I have been working on. I traced it to the fact that I ran bash with stderr not attached to a tty. I could 'fix' it by either duping stderr to stdout, or patching bash to not worry about stderr not being a terminal. Since I actually wanted to seperate the stdout and stderr output of the shell and child processes, I ended up patching bash. I don't know if this is your issue. DF
Re: SIGTTOU handling
On Mon, Nov 12, 2007 at 08:03:38PM +, Derek Fawcus wrote: > On Sun, Nov 11, 2007 at 09:56:11PM -0800, [EMAIL PROTECTED] wrote: > > Can someone provide a hint to this end? My deepest > > thanks for your time and any advice you might be > > able to provide. > > I get exactly that behaviour with a program I have been working on. Oops - not exactly the same (bad memory) - just very similar. I was getting a failure in tcsetattr (I think) on trying to resume a job. So probably not the same cause. DF
Re: SIGTTOU handling
On Sun, Nov 11, 2007 at 09:56:11PM -0800, [EMAIL PROTECTED] wrote: > > I had some difficulties getting job control working at > first. I found that having the child process do a > setpgrp() before forking to the bash instance made the > error message about disabling job control go away. Try setsid() instead.
Re: memory leak in read builtin
> > That code is quite different in bash-3.2, and the memory leak is gone. > > Definitely neither. Oh, there's no question there's a leak. It just doesn't appear to have any consequences on my systems. It will get fixed. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://tiswww.tis.case.edu/~chet/
Re: SIGTTOU handling
Hi Derek: Thanks for the input. I know that stderr is duplicated, so that's not a problem. I long suspected terminal problems, but I know that openpty is setting the term correctly from when I was mucking around with whether or not I wanted the terminal running in canonical mode. I changed out the call to setsid, but that didn't change anything. I've also tried using tcsetpgrp() and calling fork() and exit() to make the shell an orphaned process -- neither of which seemed to do any good. I used to suspect that the pty wasn't set up correctly and I eventually ended up duplicating the termios structure bit by bit and setting the pty to the characteristics that a pty from ssh gets, but that didn't do the trick either. That suggests to me that the problem isn't terminal related, but rather that it's related to the setup of the child process. Maybe this is the fault of an environment variable? -Phil
