Re: [PATCH v3] startup: add support for <file>:<line> format

[Benno Schulenberg]

Op 28-02-2023 om 18:25 schreef Benjamin Valentin:
> +                       char *filename = argv[optind++];
> +                       char *colon = filename + 1;

If the filename is empty (unlikely, but possible), then this would
step beyond the filename, to the next argument, or into unknown
territory.  For example:

    src/nano --ignore "" README:55

This opens a blank buffer and opens the README file at line 1.
The latter is not right.  So... the "+ 1" should be done only
when the filename is not empty:

   char *colon = filename + (*filename ? 1 : 0);


> +                       memmove(colon - 1, colon + 1, len);

This removes both the backslash *and* the colon.  That is not right.

After correcting that (moving the "+ 1" to the next argument), I was
curious how many filenames on my system contain a colon:

    locate : | wc -l
    7660

And how many of these would need to have their colon(s) escaped in
order for the patched nano to open them correctly:

    locate --regex ":[0-9]+(:[0-9]+)?$" | wc -l
    2

On my second machine this last number is 5.  None of those seven
files look like something that the user would want to open in an
editor, so... it might be relatively low risk to include this
colon parsing into nano by default.

After doing 'cp README example:22' and then trying:

    src/nano example:22:77
    src/nano example\:22:77
    src/nano example\\:22:77

The first two invocations open a new, blank file 'example'.
Only the latter opens the file 'example:22' at line 77.

So, escaping a colon requires preceding it with a double backslash,
because apparently the shell interprets backslash escapes too --
tested in bash, csh, ksh, and zsh, so I guess all shells do this.

Benno

OpenPGP_signature
Description: OpenPGP digital signature