On Thu, Sep 24, 2015 at 05:25:47AM -0700, Eric Dumazet wrote: > On Thu, 2015-09-24 at 13:16 +0200, Phil Sutter wrote: > > Hi, > > > > Currently, ss scales it's output to the available horizontal screen > > space available, so that the regular columns (Netid, State, Recv-Q, > > Send-Q, Local Address:Port and Peer Address:Port) use the maximum space > > available and extended information (e.g. users) get wrapped into a new > > line. > > > > While this approach is sufficient for smaller terminals to improve > > readability, it's kind of awkward in full-screen terminals which provide > > enough space to display everything on the same line. > > > > On the other hand, the current approach makes sense in that the output > > width is hard to predict: Unix domain sockets have a filesystem path as > > local address, which might be really long (e.g. 68 characters for a > > libvirt socket on my box). The '-p' flag prints process names, so > > extended information might become very long as well. The actual width of > > each line's fields is not known before it has been printed. Since input > > potentially comes from netlink, there is no random access which could be > > used to scroll quickly through the input and find each column's longest > > field. > > > > There are a number of possible ways to improve this: > > > > 1. Introduce scalemax parameter: > > This parameter specifies the maximum terminal width to scale to. > > Implementation is trivial, and works well for me as my terminals are > > either 95, 126 or 193 characters wide. Setting scalemax to 128 leaves > > line wrapping in place in all but full-screen mode. Though other's > > mileage may vary, and fiddling with this number is inconvenient as > > well. > > The big ss mistake was to not insert a new line before 'extended' info > (this gives uid: ino: and sk: fields) > > "ss -te | more" only gives one line per socket today > > But "ss -ti" gives 2 lines per socket > > Not sure we can change this. Maybe make it conditional to > if (isatty(STDOUT_FILENO)) > > (If stdout is a terminal, then cap the screen_width to 100 but insert a > new line before extended) > > I very often use "ss -tei|more" to get rid of these extra long lines, so > I would vote to cap screen_width to 100 anyway.
This is because TIOCGWINSZ returns 80 if the output is a pipe. This means that with '| more', output is simply scaled to 80 columns instead of what your actual terminal width is. Inserting a newline instead of leaving the wrapping to the terminal would mean to enforce two lined output in any case. Then your '| more' trick (which is nice, btw) would not work anymore. In general I think the wrapping is a good thing to do, as this way you can maximise a terminal afterwards and get cleaner output. Of course, repeating the command in the maximised terminal will make it messy again. :) Thanks, Phil -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html