On Friday, December 09, 2011 04:35:11 PM Chet Ramey wrote:
> On 12/9/11 10:12 AM, Jean-Jacques Brucker wrote:
> > Playing with flock to securely access to a file shared by multiple
> > process. I noticed there are no documented way to do an lseek on an
>
> > opened fd with bash :
> [...]
>
> > I have solve my problem by making this small binary (i just needed a
> > rewind) :
> >
> > int main(int argc,char * argv[]) { return lseek(atoi(argv[1]),0L,0); }
> >
> > But i ll be glad to use a standard and finished tool.
> >
> > Of course we could make an "lseek" binary with some options to cover
> > all use cases of lseek function. But I prefer to have such
> > functionality inside bash.
>
> ksh93 has this functionality with different syntax. I'm not convinced
> it's of general enough value to add to bash, especially when a separate
> binary (of obviously trivial complexity) does the job.
>
> Chet<# and <## are a little silly but fun to play with. I wouldn't call it a top priority, but hypothetically if you wanted to get a lot of power out of one extra bit of syntax you could do worse than <#((expr)). It pretty much takes care of most common seek functionality found in the fancy FD objects of other languages. I'd agree lseek alone isn't all that useful. More generally, being able to store $CUR and then later jump to it directly should be a big improvment over the sort of hack you'd have to pull in Bash to do the same. (Maybe track position by either looping with read -N, or piping through tee >(wc -m), then exploit /dev/stdin to get back to the beginning and seek forward again... Yuck.) Basic I/O isn't something I like to repeatedly fork little external processes to achieve. The zsh MULTIOS concept is interesting to that end but probably a bit over-the-top for Bash. Dan Douglas
signature.asc
Description: This is a digitally signed message part.
