Description of problem: 1) --name and --ticket-number do not have any effect in interactive mode. I propose to make these entered values defaults when asking interactively for them. 2) --ticket-number is not sanitized correctly, eg: 'a0.x12' => '012' 'one' => '' 3) --name being eg '#' translates into empty name, resulting in sosreport names like: /tmp/sosreport--20120516131727-5aad.tar.xz /tmp/sosreport-.1-20120516131747-2013.tar.xz Version-Release number of selected component (if applicable): sos-2.2-17.el6.noarch How reproducible: Always Steps to Reproduce: 1. see above 2. 3. Actual results: Expected results: Additional info:
Additional case to consider: # sosreport --batch --build -o general --name general ... sosreport build tree is located at : /tmp/dhcp-25-214-2012051708151337235309 Would be nice to have it eg. in /tmp/sosreport-general-2012051708151337235309
Setting the defaults for interactive mode is definitely a change we should make. This is how a reasonable user might expect the options to behave and there's no reason not to. For changing directory or report name structures I think this needs a bit of thought; we need to understand what dependencies people might have on these names and avoid breaking that unnecessarily. I don't personally like the current scheme much but it has been around for some time and we may have to honour it at least for the life of already-released versions.
> For changing directory or report name structures I think this needs a bit of > thought; we need to understand what dependencies people might have on these > names and avoid breaking that unnecessarily. I don't personally like the > current scheme much but it has been around for some time and we may have to > honour it at least for the life of already-released versions. Ah, correct. I didn't notice that this is actually same directory (name) as present in the tarball. Hence it is not --build dependent and change could harm users, therefore I agree to let it be as is for now.
fwiw I think --build is a stupid name. I'd be open to changing this upstream to something more obvious like --keep or --no-package.
Actually with the current el6 package I do see --name and --ticket-number propagating correctly in both interactive and batch mode (happens in preWork outside the !batch branch): # sosreport [..] Please enter your first initial and last name [rhel6-vm1]: brubble Please enter the case number that you are generating this report for: 12345 [...] Your sosreport has been generated and saved in: /tmp/sosreport-brubble.12345-20121015184743-c947.tar.xz # sosreport --batch --name fflintstone --ticket-number 54321 Your sosreport has been generated and saved in: /tmp/sosreport-fflintstone.54321-20121015184821-8273.tar.xz I'll add a check for an empty name for 6.3 and replace it with the string 'default'; I think for the numbers there's not much sense in changing it now. We've never strongly checked these before and the existing behaviour is to just drop the ticket number from the format strings if it is empty. I'd rather not change that in RHEL6 for now (I doubt anyone relies on it but you never know) - at least we manage to generate something even if the user enters nonsense.
Now behaves like this: # sosreport --name batman --ticket 314159 sosreport (version 2.2) This utility will collect some detailed information about the hardware and setup of your Red Hat Enterprise Linux system. The information is collected and an archive is packaged under /tmp, which you can send to a support representative. Red Hat Enterprise Linux will use this information for diagnostic purposes ONLY and it will be considered confidential information. This process may take a while to complete. No changes will be made to your system. Press ENTER to continue, or CTRL-C to quit. Please enter your first initial and last name [batman]: Please enter the case number that you are generating this report for [314159]: Running plugins. Please wait ... [...]
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2013-0474.html