Your input: effects of truncating hw path in lanscan?

[marie-noelle jeanson_1]

Hi,

In future HP-UX releases, HP may have to deal with longer hw paths, therefore output of commands such as lanscan may go beyong the 80 chars of a line.

We would like to have your input as users on the following:

1. how disruptive would it be to have an output line go beyond 80 chars? why?

2. how disruptive would it be to truncate the hw path in the default output (for instance, showing 0/1/2/0*) and to show the whole hw path in the verbose mode only?

Any chance we would break your scripts doing so? Do your scripts analyze the contents or just the number of fields?

Note: same problem may happen in ioscan.
What looks like the best alternative to the problem of line length? Any other ideas?

Thanks,

Marie.

[TwoProc]

Wow, I've never imagined paths that long. Can we ask what would cause paths to be that long?


However, I think for compatibility reasons, it would have to live in the same line as it does now. But, via command line switches different formatting options could be offered, as the ability to wrap a path at least on its own line would be nicer for visual presentation.

[Bill Hassell]

Whatever you do, do *NOT* split the line like bdf does. I'm sure some script writers assume column positions but after a few sysadmin scripts, they'll find out about awk and whitespace fields. For backward compatibility, I would just keep extending the field width as needed and keep the field count the same. You can always add a -n (nice format, like vmstat) which removes intermediate path info, something like:

0/1..15/2

which provides base and detailed info (better than 0/1/2*).

vmstat has survived for years with default output longer than 80 characters and ioscan has been (slightly) exceeding 80 characters for a long time too. The key is that the field count stays the same for parsing.

A nice feature would be to add a no-header option so script writers don't have to strip line 1 off the commands.