> Roland Mainz wrote:
> > Casper.Dik at Sun.COM wrote:
> > > >I would propose something like a new builtin command called "streamctl"
> > > >(stream control) which has sub-commands for testing whether a stream is
> > > >seekable, do various seeking operations (seek_to_position, seek_hole,
> > > >seek_data), list_substreams and split_substreams (the last two things
> > > >are for SCTP&co.).
> > > >Comments/suggestions/ideas welcome...
> > >
> > > Why not just an "lseek" command?
> >
> > Sounds good (except that it lacks the SCTP stuff, but I guess it should
> > better be offloaded to something like "sctpstreamctl"...) ... I'll write
> > a proposal...
>
> -- snip --
> NAME
> lseek(1) - move file pointer in a shell stream
>
> SYNOPSIS
> lseek fildes command [offset]
>
> DESCRIPTION
> The lseek shell builtin function sets the file pointer
> associated with the open file descriptor specified by fildes
> as follows:
>
> o If command is SEEK_SET, the pointer is set to offset
> bytes.
>
> o If command is SEEK_CUR, the pointer is set to its
> current location plus offset.
>
> o If command is SEEK_END, the pointer is set to the size
> of the file plus offset.
>
> o If command is SEEK_HOLE, the pointer is set to the
> next hole (in a sparse file) past "offset".
>
> o If command is SEEK_DATA, the pointer is set to the
> next data (in a sparse file) past "offset".
>
> o If command is IS_SEEKABLE lseek returns 0 as exit result
> if the stream is seekable, 1 otherwise.
>
> o If command is TELL lseek returns the current file position
> to stdout
> ...
> -- snip --
> At this point I hit a couple of problems:
> - How should we handle the return value ? lseek(2) returns the current
> file position - should lseek(1) simply return the current file position
> to stdout (and add a -q option to make lseek(1) "quiet") ?
> - Currently there is only support for seeking n-bytes. But what about
> characters in multibyte locales (CC:'ing Ienup Sung <Ienup.Sung at Sun.COM>
> and i18n-discuss at opensolaris.org for that issue) ?
> - Are there other seek-like operations which should be added here ?
> - What about syntax - should "command" come before "offset" or should
> the traditional lseek(2) syntax ordering used here (e.g. "lseek fildes
> offset command" (that's a question for David/Glenn/Casper)) ?
>
> Finally the compatibility question: Is there *ANY* operating system
> which provides a "lseek" command ?
>
> ----
>
> Bye,
> Roland
>
I see no advantage for adding a built-in for this.
The new <# operator should be able to do everything that can
be done with a built-in, and it makes it easy to apply to
files that are passed down. For example,
cksum < file <# ((4))
performs that check sum for file excluding the first 4 bytes.
Note, that in <# always produced a syntax error in earlier
versions of ksh, so that no script breaks with this
change. Currently, EOF and CUR variables are defined when processing
the arithmetic expression, but it could be extended to add the
variables HOLE and DATA should these become standard lseek extensions.
I expect to extend <# to allow it to be followed by a pattern.
This will cause the shel to read forward until the next line
that contains the specified pattern. While this is slower than
lseek(), it should speed up scripts that do
while read -r
do if [[ $REPLY == pattern ]]
then ...
fi
done
by using
while < file <# pattern
do
...
done
The reason that the read is not needed, is because of a currently
undocumented ksh93 feature, that makes
while < file
do ...
done
equivalent to
while read -r
do set -- $REPLY
...
done < file
but runs much faster.
David Korn
dgk at research.att.com
