Hi! I'm back. On Mon, Jul 7, 2014 at 8:40 AM, Pádraig Brady <p...@draigbrady.com> 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. Thanks, deymo.