Strange occurance when mixing "set proc/unit=byte" and pipe

[Ken Robinson]

I noticed a very strange (reproducible) bug today on both V7.3-2 and v8.3-1h1

Do the following:

$ set proc/unit=byte
$ sho dev d/mou ! this is fine -- the free space shows as bytes
$ pipe sho dev d/mou ! this is also fine
$ pipe sho dev d/mou | type sys$pipe ! what happened? the free space shows as blocks
$ pipe sho dev d/mou/un=by | type sys$pipe ! ok again, but I shouldn't have do that

This also happens when you pipe the output of the directory/size command to another process.

Ken

[Steven Schweda]

SPAWN, and the subprocess also has forgotten:

alp $ show proc /unit
[...]
Units: Bytes

alp $ spawn
%DCL-S-SPAWNED, process SMS_44309 spawned
%DCL-S-ATTACHED, terminal now attached to process SMS_44309

alp $ show proc /unit
[...]
Units: Blocks

Knowing nothing, I'd guess that these
phenomena are related.

[Willem Grooters]

$ SET POCESS => sets attributes for THIS process.

$ SPAWN creates a new process - with the default setting: Blocks.

$ PIPE can be thought of creating a new process by, or similar to SPAWN, execute the FIRST command in that context, and, in the current process, process the output of the subprocess.
In your example. the created process would execute SHO DEV D/MOU, and pass the units in blocks (being the default setting) to the main process, wheer it will show in blocks. If you specify /UN=BY, the created process will do the math, and you'll see the units in bytes.

To be sure: $ SET PROCESS/UNIT-BLOCKS
and re-execute the second command. You'll get the info - in BYTES.

(not tested, but deducted)

[Robert Gezelter]

Ken,

I agree with Steve and Willem.

This is one of those debates about what the proper things to propagate when SPAWN is invoked. There is an argument for a greater set of process parameters to be "cloned" when a SPAWN is done, i.e., there is a strong argument that a whole set of settable parameters should be cloned, or at least the default should be that they are cloned. Among these parameters are RMS parameters, and various process settings. Insofar as I recall, only the DEFAULT string, symbols, and process logical names are cloned.

I suspect that you are not the first to notice this inconsistency.

Perhaps a "feature" request to Engineering for SET PROCESS/SPAWN_MODE=CLONE|RAW or SET PROCESS/SPAWN=([NO]LOGICAL_NAME,[NO]RMS,[NO]SYMBOL, [NO]SETTINGS])?

- Bob Gezelter, http://www.rlgsc.com

[Willem Grooters]

@rob:

I agree. Even more, I would like to see both implemented: first for a quick, basic setting (RAW = inherit nothing, CLOSE=inherit all) and the second for a specific one; RAW or CLONE taking precedence.

Does the advocay still exist, or an alternative site?

[Steven Schweda]

> This is one of those debates about what the
> proper things to propagate when SPAWN is
> invoked. [...]

Yup. Try it with something similar, like
"Parse Style" or "Case Lookup". Around here,
those two get inherited. "Units" getting
lost looks to me like a bug. (Of course,
"Image Dump" gets lost, too, but that's more
reasonable, I'd say.)

[Steven Schweda]

And, in any case, if SPAWN got more options
to deal with these choices, then PIPE would
need similar changes to deal with the
original complaint.

[Jan van den Ende]

All,

advocacy does not exist anymore, but if anyone gets a formal request trough, point thm to this thread also. In which case I can be counted as another vote in favor.

Re Stevens last remark: I think that calls for another process setting to define which properties to inherit by PIPE and SPAWN (and similar others? Which?). Of course, any qualifier specified with a specific command should take precedence over the process setting.

Proost.

Have one on me.

jpe

[Ken Robinson]

Thanks for everyone chipping in as to why I was seeing the "problem".

Ken

[Hoff]

$loop:
$ candidate = f$device(,1,,)
$ if candidate .eqs. "" then exit
$ if f$getdvi(candidate,"MNT")
$ then
$ freeblocks = f$getdvi(candidate,"FREEBLOCKS")
$ write sys$output "Device ''candidate' has ''freeblocks' blocks free"
$ endif
$ goto loop