Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Created attachment 492025[details]
Allow linux to use its own getopt
Description of problem:
If one wishes to use getopt_long in the ssh program, then one is confronted with issues because openssh uses an in-tree implementation of getopt based on the BSD implementation.
Version-Release number of selected component (if applicable):
openssh-5.3p1-20.el6_0.3.x86_64
How reproducible:
Always after making a trivial (at face value) conversion to getopt_long
Steps to Reproduce:
Setting up the appropriate variables including struct option list of a single { 0, 0, 0, 0 } element, and the required index variables, then calling getopt_long instead of getopt. None of the parameters can receive the optarg string
Actual results:
Even existing command line params that expect arguments are presented with an optarg value that is always NULL, the same goes for long options
Expected results:
optarg is not NULL, existing params receive their arguments as with getopt
Additional info:
This patch was motivated by an internal change I was making to add a custom command line flag to the ssh client. Seeing as many single character flags are used already, I decided to use a long option to make it distinct and lessen chances of conflicts with common releases of openssh.
During openssh configure, the host system is queried for the existence of an exported variable 'optreset', which is present in the BSD c library, but not in glibc. If not found, as it is in linux, openssh then goes an aliases the getopt function and it's associated exported variables with those found in an in-tree BSD compat implementation of getopt using C macros, this alternative implementation of getopt provides optreset.
The alternative BSD getopt provides... getopt, but it doesn't provide getopt_long, so when one invokes that, they are getting the glibc version, which treats the exported variables differently to BSD, and hilarity ensues.
My patch addressing the issue doesn't try to use getopt_long, it just allows linux to use the glibc getopt, and the glibc (and other non-BSD C libraries) method of resetting the getopt parse. It sets the stage for one to use getopt_long if they wish.
I hope somebody can find this useful.
Did you consult the patch with the upstream? What is the upstream meaning? Have any reference to the mindrot bugzilla or openssh-devel mail list with the discussion?
You are right, I should consult upstream about this.
In addition, I think a better alternative would be to add getopt_long implementation to the in-tree BSD solution, rather than create more linkages with the external environment. Openssh is a ported project after all, and not initially developed for Linux.
Created attachment 492025 [details] Allow linux to use its own getopt Description of problem: If one wishes to use getopt_long in the ssh program, then one is confronted with issues because openssh uses an in-tree implementation of getopt based on the BSD implementation. Version-Release number of selected component (if applicable): openssh-5.3p1-20.el6_0.3.x86_64 How reproducible: Always after making a trivial (at face value) conversion to getopt_long Steps to Reproduce: Setting up the appropriate variables including struct option list of a single { 0, 0, 0, 0 } element, and the required index variables, then calling getopt_long instead of getopt. None of the parameters can receive the optarg string Actual results: Even existing command line params that expect arguments are presented with an optarg value that is always NULL, the same goes for long options Expected results: optarg is not NULL, existing params receive their arguments as with getopt Additional info: This patch was motivated by an internal change I was making to add a custom command line flag to the ssh client. Seeing as many single character flags are used already, I decided to use a long option to make it distinct and lessen chances of conflicts with common releases of openssh. During openssh configure, the host system is queried for the existence of an exported variable 'optreset', which is present in the BSD c library, but not in glibc. If not found, as it is in linux, openssh then goes an aliases the getopt function and it's associated exported variables with those found in an in-tree BSD compat implementation of getopt using C macros, this alternative implementation of getopt provides optreset. The alternative BSD getopt provides... getopt, but it doesn't provide getopt_long, so when one invokes that, they are getting the glibc version, which treats the exported variables differently to BSD, and hilarity ensues. My patch addressing the issue doesn't try to use getopt_long, it just allows linux to use the glibc getopt, and the glibc (and other non-BSD C libraries) method of resetting the getopt parse. It sets the stage for one to use getopt_long if they wish. I hope somebody can find this useful.