Re: dc.1: document non-portability of `e'
On Mon, Nov 27, 2017 at 07:00:51PM +0100, Otto Moerbeek wrote: > On Mon, Nov 27, 2017 at 10:34:50AM +, Jason McIntyre wrote: > > > On Sun, Nov 26, 2017 at 07:18:33PM +, kshe wrote: > > > Hi, > > > > > > The manual page for dc(1) is very careful about signalling which > > > commands are non-portable extensions, with the exception of the `e' > > > command, which is a more recent addition. > > > > > > Index: dc.1 > > > === > > > RCS file: /cvs/src/usr.bin/dc/dc.1,v > > > retrieving revision 1.30 > > > diff -u -p -r1.30 dc.1 > > > --- dc.1 23 Feb 2017 06:40:17 - 1.30 > > > +++ dc.1 26 Oct 2017 04:44:01 - > > > @@ -189,6 +189,7 @@ The top value on the stack is duplicated > > > Equivalent to > > > .Ic p , > > > except that the output is written to the standard error stream. > > > +This is a non-portable extension. > > > .It Ic f > > > All values on the stack are printed, separated by newlines. > > > .It Ic G > > > > > > Regards, > > > > > > kshe > > > > > > > morning. > > > > posix doesn;t describe a separate dc utility, as far as i can see. the > > STANDARDS section of dc(1) discusses only the "arithmetic operations" of > > dc. > > > > bc(1) however does describe -e as an extension, in STANDARDS. > > > > i think here dc(1) is a bit of a special case, but i think how it is now > > is fine. i definitely don;t want to start plastering "this is an > > extension" onto the end of every option not described by posix. > > > > jmc > > This is not about the -e flag but about the 'e' command. The frame of > reference is the set of command implemented by the original dc(1). I > think it is a good think to mention that 'e' is non-portable. > > -Otto > fair enough, but in STANDARDS... jmc
Re: dc.1: document non-portability of `e'
On Mon, Nov 27, 2017 at 10:34:50AM +, Jason McIntyre wrote: > On Sun, Nov 26, 2017 at 07:18:33PM +, kshe wrote: > > Hi, > > > > The manual page for dc(1) is very careful about signalling which > > commands are non-portable extensions, with the exception of the `e' > > command, which is a more recent addition. > > > > Index: dc.1 > > === > > RCS file: /cvs/src/usr.bin/dc/dc.1,v > > retrieving revision 1.30 > > diff -u -p -r1.30 dc.1 > > --- dc.123 Feb 2017 06:40:17 - 1.30 > > +++ dc.126 Oct 2017 04:44:01 - > > @@ -189,6 +189,7 @@ The top value on the stack is duplicated > > Equivalent to > > .Ic p , > > except that the output is written to the standard error stream. > > +This is a non-portable extension. > > .It Ic f > > All values on the stack are printed, separated by newlines. > > .It Ic G > > > > Regards, > > > > kshe > > > > morning. > > posix doesn;t describe a separate dc utility, as far as i can see. the > STANDARDS section of dc(1) discusses only the "arithmetic operations" of > dc. > > bc(1) however does describe -e as an extension, in STANDARDS. > > i think here dc(1) is a bit of a special case, but i think how it is now > is fine. i definitely don;t want to start plastering "this is an > extension" onto the end of every option not described by posix. > > jmc This is not about the -e flag but about the 'e' command. The frame of reference is the set of command implemented by the original dc(1). I think it is a good think to mention that 'e' is non-portable. -Otto
Re: dc.1: document non-portability of `e'
On Sun, Nov 26, 2017 at 07:18:33PM +, kshe wrote: > Hi, > > The manual page for dc(1) is very careful about signalling which > commands are non-portable extensions, with the exception of the `e' > command, which is a more recent addition. > > Index: dc.1 > === > RCS file: /cvs/src/usr.bin/dc/dc.1,v > retrieving revision 1.30 > diff -u -p -r1.30 dc.1 > --- dc.1 23 Feb 2017 06:40:17 - 1.30 > +++ dc.1 26 Oct 2017 04:44:01 - > @@ -189,6 +189,7 @@ The top value on the stack is duplicated > Equivalent to > .Ic p , > except that the output is written to the standard error stream. > +This is a non-portable extension. > .It Ic f > All values on the stack are printed, separated by newlines. > .It Ic G > > Regards, > > kshe > morning. posix doesn;t describe a separate dc utility, as far as i can see. the STANDARDS section of dc(1) discusses only the "arithmetic operations" of dc. bc(1) however does describe -e as an extension, in STANDARDS. i think here dc(1) is a bit of a special case, but i think how it is now is fine. i definitely don;t want to start plastering "this is an extension" onto the end of every option not described by posix. jmc
