Implement a "--patch" argument

[hlechner]

For who is trying to install specific old versions of nodejs on FreeBSD will face the issue #900.

However there is a good workaround to help the FreeBSD users to install it still using the nvm, it receive the list of patchs files and apply it after the checksum check.

For example:

--patch="file1.patch","file2.patch"

It's a bit manually but make it a lot easier, for example, I'm developing a shell script for a project and I've changed it to work on FreeBSD too, With that implementation I can instruct to download the patchs and apply on nvm or I can do it by myself through shell script.

[ljharb]

So this would be a special argument to nvm install that would only apply in source mode (like -j is now)? How would it apply the patch exactly?

[hlechner]

Yes, It should be only for source code, the the command would be something like that:
nvm install v0.9.3 --patch="file1.patch","file2.patch"

The script will start normally, download the file, make the checksum check and from there will apply the patch on the nvm source directory (for example: ~/.nvm/src/node-v0.9.3)

the command-line syntax is like that:

patch < file1.patch
patch < file2.patch

the commands above just need be executed in the node src directory (~/.nvm/src/node-v0.9.3)

after applying the patchs just proceed normally.

[ljharb]

Is patch part of POSIX?

[hlechner]

Not sure, I always use it on all linux that I had, let me google it if I found the answer.

[hlechner]

From what I see right now, Linux distributions uses the GNU Patch, there are some notes about the traditional old patch POSIX:

COMPATIBILITY ISSUES
       The POSIX standard specifies behavior that differs from patch's traditional behavior.  You should be aware of these differences if you must interoperate with patch versions 2.1 and earlier, which do not conform to POSIX.

        · In  traditional  patch, the -p option's operand was optional, and a bare -p was equivalent to -p0.  The -p option now requires an operand, and -p 0 is now equivalent to -p0.  For maximum compatibility, use options like -p0
          and -p1.

          Also, traditional patch simply counted slashes when stripping path prefixes; patch now counts pathname components.  That is, a sequence of one or more adjacent slashes now counts as a single slash.  For  maximum  portabil‐
          ity, avoid sending patches containing // in file names.

        · In traditional patch, backups were enabled by default.  This behavior is now enabled with the -b or --backup option.

          Conversely,  in  POSIX  patch, backups are never made, even when there is a mismatch.  In GNU patch, this behavior is enabled with the --no-backup-if-mismatch option, or by conforming to POSIX with the --posix option or by
          setting the POSIXLY_CORRECT environment variable.

          The -b suffix option of traditional patch is equivalent to the -b -z suffix options of GNU patch.

        · Traditional patch used a complicated (and incompletely documented) method to intuit the name of the file to be patched from the patch header.  This method did not conform to POSIX, and had a few gotchas.  Now patch uses  a
          different,  equally  complicated (but better documented) method that is optionally POSIX-conforming; we hope it has fewer gotchas.  The two methods are compatible if the file names in the context diff header and the Index:
          line are all identical after prefix-stripping.  Your patch is normally compatible if each header's file names all contain the same number of slashes.

        · When traditional patch asked the user a question, it sent the question to standard error and looked for an answer from the first file in the following list that was a terminal: standard error,  standard  output,  /dev/tty,
          and standard input.  Now patch sends questions to standard output and gets answers from /dev/tty.  Defaults for some answers have been changed so that patch never goes into an infinite loop when using default answers.

        · Traditional patch exited with a status value that counted the number of bad hunks, or with status 1 if there was real trouble.  Now patch exits with status 1 if some hunks failed, or with 2 if there was real trouble.

        · Limit  yourself  to the following options when sending instructions meant to be executed by anyone running GNU patch, traditional patch, or a patch that conforms to POSIX.  Spaces are significant in the following list, and
          operands are required.

             -c
             -d dir
             -D define
             -e
             -l
             -n
             -N
             -o outfile
             -pnum
             -R
             -r rejectfile

FreeBSD uses their own patch program (probably due to license issue): patch 2.0-12u10 FreeBSD

     --posix
             Enables strict IEEE Std 1003.1-2008 (“POSIX.1”) conformance,
             specifically:

             1.   Backup files are not created unless the -b option is speci‐
                  fied.

             2.   If unspecified, the file name used is the first of the old,
                  new and index files that exists.


STANDARDS
     The patch utility is compliant with the IEEE Std 1003.1-2008 (“POSIX.1”)
     specification, except as detailed above for the --posix option.

     The flags [-BCEFfstVvxz] and [--posix] are extensions to that specifica‐
     tion.

Looking for Mac OSX on internet seems to uses the GNU Patch too: https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/patch.1.html

However in my perception, it would not try to be complex, if someone needs to use some advanced option this user must do it manually instead of just execute the "--patch" argument

[ljharb]

My concern is that if it's not going to succeed, it should fail - meaning, --patch would need to account for any differences (that won't already cause it to error out).

[hlechner]

I think it would affect more the advanced option than just applying the file into a current directory as default options.

I can make tests to make sure it wouldn't fail by different patch applications. But in case the problem isn't caused by the patch application but in user patch file (maybe the user select the wrong patch file) I think it should be throw the error on screen and exit the nvm.

Any other concern?

[ljharb]

I agree, if the patch won't complete successfully I would want it to exit nvm and print an error.

I don't think I have any other concerns as long as the feature was accompanied by solid tests :-) PRs welcome!

[ljharb]

This is related to #1207.

[ljharb]

I'm closing this, since the solution to #1207 should work here.