I suggest adding another formal argument that will hold the returned
seek value. The function return code can then always return 0 for SUCCESS
or 1 for FAILURE (with the possible exception of IS_SEEKABLE).
Cheers,
Mario DeFazio
Korn Shell user since 1983
Roland Mainz wrote:
> 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
>
