On 07/08/2014 04:23 AM, Alex Deymo wrote: > Hi! > I'm back. > > On Mon, Jul 7, 2014 at 8:40 AM, Pádraig Brady <[email protected] > <mailto:[email protected]>> wrote: > > On 07/07/2014 12:41 AM, Bernhard Voelker wrote: > > On 07/05/2014 03:40 PM, Pádraig Brady wrote: > > > > 15. src/coreutils-{arch,dir,vdir}.c wrapper: > > Why don't we do this also in non-single-binary case? ;-) > > leaving as is for now > > > Doing this in the non-single-binary case doesn't help much. In the current > code, these three binaries differ only in the value of a variable in the > .data section. Using the single-binary code, they would differ is some code > that runs and sets that value accordingly. > > > Changes are attached to this email. > > Rolled up patch is at: > http://www.pixelbeat.org/cu/single-binary_v9.patch > > One other change to consider is that we might > change `coreutils --coreutils-prog=` to `coreutils --program` > as the former is a bit long/awkward/redundant? > > > The idea of the awkward/redundant flag is that it is unique. The current > coreutils.c checks both the argv[0] and the --coreutils-prog= flag as > argv[1]. The flag is only used internally and users should not pass that flag > to any other program, so the code works either for symlinks o shebangs. If > you want to change the flag to something shorter like "--program" then we > should also pass a compile-time value to coreutils.c to tell it where to read > the program name from (argv[0] basename or a suffix of argv[1]) > > Another thing I just thought of is that we should change the ENOENT > warning in coreutils.c to something explicit as the error > pertains to internal functionality, rather than optional > external links/scripts etc. > > > Let me know if you want me to work on these changes (or other) so we don't > duplicate the work.
If you could look at it it would be great thanks. There's the above --coreutils-prog possible adjustment and the man page issues Bernhard mentioned. Re the --coreutils-prog adjustment, if we were adding a compile time adjustment, then it might be possible to do away with an option altogether. i.e. support: coreutils ls ... I'm not pushed either way TBH as I mainly see the explicit coreutils invocation as a means to support the shebangs method. thanks, Pádraig.
