Re: lseek with bash

[Dan Douglas]

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.