Description of problem: Current behavior of -a option is little bit strange. If I don't provide filename, it will fail. If I do, it will be read as a file. So far, so good. But if I provide string "False", it will read stdin. I believe culprit is this code: if options.analyze: validate_invocation_style("analyze", options, conflict_opts) use_terminal = True if options.analyze != "False": logfile = options.analyze else: logfile = "/dev/stdin" Since default value of the option is False---the special object, not str("False"), the last line will only be reached if "False" is provided as filename. Version-Release number of selected component (if applicable): setroubleshoot-3.2.17-1.fc20.x86_64 How reproducible: always Steps to Reproduce: 1. sealert -a False Actual results: reads from /dev/stdin Expected results: reads from ./
Created attachment 939398 [details] default-to-stdin.patch This will cause 'logfile' default to '/dev/stdin', changing it to value given, unless it's "-". New behavior is: * `sealert -a` - fails * `sealert -a -` - reads from /dev/stdin * `sealert -a anything_else` - reeds from anything_else
Note that making `sealert -a` read from stdin would make sense, although optparse intentionally does not support this[1]: > Typically, a given option either takes an argument or it doesn’t. Lots of > people want an “optional option arguments” feature, meaning that some > options will take an argument if they see it, and won’t if they don’t. > This is somewhat controversial, because it makes parsing ambiguous: > if -a takes an optional argument and -b is another option entirely, how > do we interpret -ab? Because of this ambiguity, optparse does not support > this feature. [1]: https://docs.python.org/2/library/optparse.html#terminology
Thanks for the report and the patch. I would consider this simply as a bug in code and drop reading of /dev/stdin completely. You can always use '-a /dev/stdin' if you really need it. $ sealert -a Usage: sealert [options] sealert: error: -a option requires an argument $ sealert -a False [Errno 2] No such file or directory: 'False' $ sealert -a - [Errno 2] No such file or directory: '-' https://github.com/fedora-selinux/setroubleshoot/commit/ee18abf4c8839fa9766302415bb3b2fb4cc5d6a7
setroubleshoot-3.2.23-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/setroubleshoot-3.2.23-1.fc22
setroubleshoot-3.2.23-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/setroubleshoot-3.2.23-1.fc21
Package setroubleshoot-3.2.23-1.fc22: * should fix your issue, * was pushed to the Fedora 22 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing setroubleshoot-3.2.23-1.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-5884/setroubleshoot-3.2.23-1.fc22 then log in and leave karma (feedback).
setroubleshoot-3.2.23-1.fc22 works
setroubleshoot-3.2.23-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
setroubleshoot-3.2.23-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.