Call-by-name argument passing? Re: Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
On 5/15/06, Mario DeFazio wrote: > Personally I would like to see an expansion of the use of call-by-name > argument passing. Could you provide any examples how this should work in a shell? Irek
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
David,
Back around April 20, Roland M spec'd out an lseek proposal
and wondered how best to return the seek value.
I simply suggested the use of a call-by-name argument.
Then out of the blue today, someone asked how that would work, so I replied
to them.
While I don't have any current interest in seek'ing, your new operators
are very cool. But I am *wildly* enthusiastic about call-by-name *grin*.
Cheers,
Mario
David Korn wrote:
>
>>If lseek is external, that I would suggest a ksh builtin wrapper around it.
>>Personally I would like to see an expansion of the use of call-by-name
>>argument passing.
>>
>>
>
>
>
> Here is an example of call by name argument passing:
>
> cut here=
> function distance
> {
> nameref p=$1
> print -- $(( sqrt(p.x*p.x + p.y*p.y) ))
> }
>
> p1=(float x=3 y=4)
> p2=(float x=5 y=12)
> distance p1
> distance p2
> cut here=
> The output is
> 5
> 13
>
>
> I don't know what this has to do with lseek.
> As I reported earlier, there is no need for an lseek builtin
> since ksh93r has the ability to seek as part of the language.
>
> The new redirection operators, <# and ># are used to seek.
> For example,
> <# (( EOF-36))
> will seek to 36 bytes before the end-of-file. You can apply this
> along with any redirection so that
> cat < file <# ((80))
> will cat the file starting from offset 80.
> The value of $(n<#) is the current offset on file descriptor .
>
> The current syntax can be extended to add other seek options like
> SEEK_HOLE, by using,
> <# (( HOLE))
> to seek to the next hole.
>
>
>
> David Korn
> dgk at research.att.com
> ___
> ksh93-integration-discuss mailing list
> ksh93-integration-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
On 4/20/06, David Korn 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 > > 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. Maybe an external program for this may make the way into the POSIX standard soon - I have forwarded Roland's proposal to some external people and they seem to be interested. A built in may then the logical follow up. The built in can also deal with the support for seeking for holes and data in a file earlier than syntax extensions to the shell itself. Irek
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
On 4/20/06, Mario DeFazio wrote: > I suggest adding another formal argument that will hold the returned > seek value. And how should this work? "lseek" may be an external program without having access to the environment variables of the parent process (the shell). Therefore it cannot store the returned seek value. Irek
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
> If lseek is external, that I would suggest a ksh builtin wrapper around it.
> Personally I would like to see an expansion of the use of call-by-name
> argument passing.
>
>
Here is an example of call by name argument passing:
cut here=
function distance
{
nameref p=$1
print -- $(( sqrt(p.x*p.x + p.y*p.y) ))
}
p1=(float x=3 y=4)
p2=(float x=5 y=12)
distance p1
distance p2
cut here=
The output is
5
13
I don't know what this has to do with lseek.
As I reported earlier, there is no need for an lseek builtin
since ksh93r has the ability to seek as part of the language.
The new redirection operators, <# and ># are used to seek.
For example,
<# (( EOF-36))
will seek to 36 bytes before the end-of-file. You can apply this
along with any redirection so that
cat < file <# ((80))
will cat the file starting from offset 80.
The value of $(n<#) is the current offset on file descriptor .
The current syntax can be extended to add other seek options like
SEEK_HOLE, by using,
<# (( HOLE))
to seek to the next hole.
David Korn
dgk at research.att.com
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
I think that lseek(1) as an external program and allowing it to also seek character boundaries based on the current locale is a good idea (in addition to the byte boundaries) and also useful for numerous multibyte locales including UTF-8. Ienup I. Szczesniak wrote at 05/15/06 07:21: >> > Roland Mainz wrote: >> > ... snip... >> > - Currently there is only support for seeking n-bytes. But what about >> > characters in multibyte locales (CC:'ing Ienup Sung >> >> > and i18n-discuss at opensolaris.org for that issue) ? >> ... snip ... >> I see no advantage for adding a built-in for this. > > > Maybe an external program for this may make the way into the POSIX > standard soon - I have forwarded Roland's proposal to some external > people and they seem to be interested. A built in may then the logical > follow up. > The built in can also deal with the support for seeking for holes and > data in a file earlier than syntax extensions to the shell itself. > > Irek
Call-by-name argument passing? Re: Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
In ksh93, if you do "getopts --man" you will see this synopsis: getopts [ options ] opstring name [args...] As described in the manpage text: Each time it is invoked, the getopts utility places the value of the next option in the shell variable specified by the name operand [...] Thus the 'name' variable is a call-by-name argument. I use call-by-name all the time in my shell functions, especially with compound variables. Regards, Mario I. Szczesniak wrote: > On 5/15/06, Mario DeFazio wrote: > >> Personally I would like to see an expansion of the use of call-by-name >> argument passing. > > > Could you provide any examples how this should work in a shell? > > Irek > ___ > ksh93-integration-discuss mailing list > ksh93-integration-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/ksh93-integration-discuss >
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
I. Szczesniak wrote: > On 4/20/06, Mario DeFazio wrote: > >> I suggest adding another formal argument that will hold the returned >> seek value. > > > And how should this work? "lseek" may be an external program without > having access to the environment variables of the parent process (the > shell). Therefore it cannot store the returned seek value. > > Irek If lseek is external, that I would suggest a ksh builtin wrapper around it. Personally I would like to see an expansion of the use of call-by-name argument passing. -Mario
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
> 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 > 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
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
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 > 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 >
Proposal: New builtin command "lseek" / was: Re: [ksh93-integration-discuss] Re: [ast-users] Seeking in shellstreams...
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 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 -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
