libxo inconsistent field truncation about libxo HOT 3 OPEN

from libxo.

Thanks for the quick response!

I'm not sure if procstat actually has a limit.. It doesn't provide a maxsize to --libxo, but there may be one internally, I don't know. I just know that if there is a defined limit, it's bigger than my test data!

But, my personal opinion in all cases like this, the option should exist to have the limit, or have it unlimited. I don't even care which is default - probably having a limit at default would be a good idea to stop people kicking themselves in the face), but I think it should be consistent across all output data types.

As for "ps", the reason this got me is due to the '-ww' option. The manpage says:

-w Use at least 132 columns to display information, instead of the default which is the window size if ps is associated with a terminal. If the -w option is specified more than once, ps will use as many columns as necessary without regard for the window size. Note that this option has no effect if the “command” column is not the last column displayed.

Using -w twice, implies to me that the output won't be truncated. However, I realise this is a "ps" issue, not libxo. I just mentioned this because this is what led me to notice the way truncation is applied by libxo to different formats.

But note, as this truncation is done within ps too, even the "real" data formats will be truncated unless '-ww' is used.

This means that as things stand, if you don't use '-ww', then the data is truncated with all libxo output formats. (presumably this is a bug related to the how the code was in the pre --libxo days). However, if you specifically say "I don't want truncation", and use '-ww" then libxo truncates for some format but not others. I understand your reasoning behind ignoring truncation for "real" data formats, but in this specific situation it is confusing.

Expanding on that, if a calling program specifies a maxwidth, the user may be setting it because they don't want to deal with a potentially huge json or xml file.

I dunno. It just makes sense to me to do what the calling program asks in all cases. This is a can of worms..... I like your idea of a new field flag for this. I was going to suggest something similar, but thought it would be overkill!, and I guess this is the sort of thing the person in the freebsd bug was trying to achieve with the "am i calling libxo or not" hack which as you pointed out, wasn't a reliable solution.

If you do add this, I really don't care which option is default, as long as the option exists! In fact, But still, doing it different for one format compared to another seems wrong. I get it, but ... What happens if someone adds a different data format as a plugin? How would libxo determine if it's a "presentation" format or a "real" format? How about people who assume html should be a "real" format, in that html doesn't have issues with "line" length, and can naturally format long lines on the screen?

Anyway, my main issue is due to "ps" not "libxo", so I'll take that up there.

Sorry for being incoherent here - this is one of those issues where the more you think about it, the harder it gets!

Cheers, Jamie

from libxo.

I also note that "ps" formats it's data using vis(3), which is probably something best left to libxo... ? Another rabbit-hole!

from libxo.