On 06/14/2014 07:14 PM, John E. Malmberg wrote:
> I think there is a way to use pipe commands to do appending of output.
I don't know of any way to have that in the current pipe command I tried
(V8.3/Alpha). The only workaround seems to use append/new, but that has
some incompatibilities/limitations with piped output:
$ pipe show time
20-JUN-2014 08:24:03
$ pipe show time >x.x
$ ty x.x
20-JUN-2014 08:24:15
$ pipe show time | append/new sys$pipe x.x
$ ty x.x
20-JUN-2014 08:24:24
$ pipe show time | append/new sys$pipe x.x
$ ty x.x
20-JUN-2014 08:24:24 20-JUN-2014 08:24:29
$ dump/rec x.x
...
Record number 1 (00000001), 22 (0016) bytes, RFA(0001,0000,0000)
38302034 3130322D 4E554A2D 30322020 20-JUN-2014 08 000000
3531 3A34323A :24:15.......... 000010
Record number 2 (00000002), 22 (0016) bytes, RFA(0001,0000,001A)
38302034 3130322D 4E554A2D 30322020 20-JUN-2014 08 000000
3432 3A34323A :24:24.......... 000010
Record number 3 (00000003), 22 (0016) bytes, RFA(0001,0000,0034)
38302034 3130322D 4E554A2D 30322020 20-JUN-2014 08 000000
3932 3A34323A :24:29.......... 000010
$
> A program built on a version of VMS that does not support the longer
> command lines would not be able to see the compile time symbols that the
> support was present on, so while it could build the support in, the code
> would look different.
>
> A program built on a version of VMS that supports the longer command
> lines would not be able to run on the older versions of VMS, unless
> special (and mostly undocumented) build procedures are used.
>
> And then you need the older version of VMS to validate that the build
> works. Currently I am limited to VAX/VMS 8.3, Alpha 8.3/8.4, and
> Itanium 8.4.
>
> So that is why I consider it a compile time option.
I think I understand. So it would be a compile time option for
Alpha/I64. Or do you really have VAX/VMS 8.3? I know of 8.2 but never
saw 8.3. Again, me thinks, letting make always generate command
procedures is a much simpler approach with less code changes.
> Lexical functions work in recipe commands now. Symbol substitution does
> not. I am just looking at simulating $xxx expansion at this point, done
> before the command is run. GNU make is already supporting other bits of
> shell simulation on VMS, so the precedent of doing this type of thing
> has already been set.
As mentioned before, forced symbol substitution doesn't work with
(lib$)spawn passing a single command, any other symbol substitution
works. That includes forced symbol substitution with lexical functions,
which in this case don't work, as it is a forced symbol substitution.
With using command procedures for actions all symbol substitutions work.
> I also plan to look at having a pool of subprocesses and sending
> commands to them over mailboxes instead of spawning a new process for
> each line of a recipe. This should speed make, particularly on the
> older systems.
Then DCL has to read from the mailbox and then all the symbol
substitutions should work. To me this looks more like a ONESHELL
implementation.
Yes, even for a single action, one can replace the file based command
procedures with mailbox based command procedures. To me using mailboxes
seems to be a bigger change. With fast disks and cached files it may not
be worth the effort. But what do I know who uses old systems, anyway.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
