-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
images & containers module too table-column contents sensitive #50
Comments
This just needs to be put in place / exercised: baf2d81 |
Example output of said breaking on a docker ps -a --no-trunc --size:
This breaks the |
@Lorquas Ohhhh, nice! Yeah, those characters need to be escaped or the table is completely un-parseable. I just reproduced it simply by executing: docker run b7de3133ff98 bash -c "echo 'line one There's absolutely no practical way to parse that w/o counting opening/closing tokens. They really should have "COMMAND" as the last column of the table and escape all "special" characters (\n, \e, \r, \g, \b, etc). |
Interesting this actually works properly: docker run b7de3133ff98 bash -c "echo 'this is a really really really really super big really really really really long command' > /tmp/foobar" So the bug has to do with docker scaling column names when the column data includes special characters (newline in this case) |
Okay, the super-duper long line is now covered by unittests: cevich@fd71017 The bug however, needs to be opened and I'll work on getting the new table-parser worked into |
Okay, new table parser is now in #88 and bug is open: https://bugzilla.redhat.com/show_bug.cgi?id=1093108 |
We shouldn't rely on 'multiple-whitespace' delimiter for images and containers table parsing. For example, if a command has too many spaces in it or there's an odd line-wrap somewhere. Instead, the character-offset of each header field seems to be more accurate and I think would be less error-prone.
The text was updated successfully, but these errors were encountered: