1

I execute a set of handy commands I need to do often on a standard type of file using the -c (or equivalently, the +) option from command line using vim. However, after an update to the remote system's OS, commands beyond the first one are interpreted as different file names and results in the first command being executed and multiple buffers being opened rather than multiple commands being executed on one file.

The command I use is vim -c ':11' -c ':norm wllv,dZZ' myfile (go to line 11, move over a few characters, select the current position, and replace using a leader command, and then save and exit). With the change on the remote system, this now results in two buffers being opened, one is wllv,dZZ and the other is myfile

Vim also throws this error:

Error detected while processing command line:
E471: Argument required: :norm

Furthermore, if I try vim -c ":11" -c ":21" myfile, both commands work and no extra buffer is opened, which indicates the error is perhaps somewhere with :norm, but I'm not sure why as this was working just fine very recently.

Current version of vim is 7.4, in case that helps.

Any help restoring the old behavior or understanding where the issue is coming from would be greatly appreciated, thanks!

Added output from xxd for a bash script containing only the vim command above:

0000000: 2321 202f 6269 6e2f 6261 7368 0a76 696d  #! /bin/bash.vim
0000010: 202d 6320 273a 3131 2720 2d63 2027 3a6e   -c ':11' -c ':n
0000020: 6f72 6d20 776c 6c76 2c64 5a5a 2720 6d79  orm wllv,dZZ' my
0000030: 6669 6c65 0a                             file.

Pseudocode version of the wrapper script:

if [ $LOGNAME == "root" ]; then 
    <some logic here for when it's run by root> 
else 
    /usr/bin/vim $* 
fi
16
  • 1
    This isn't sounding like a Vim issue but it would help if you provide more details. What remote OS? How are you accessing Vim on the remote system? SSH? What SSH (or whatever) client are you using? What's the local OS? Etc.
    – B Layer
    Commented Jul 14, 2021 at 17:59
  • 1
    Can you try with a more up-to-date vim or no? My first thought was that perhaps the vim9 stuff had broken command-parsing but that shouldn't apply to such an old vim
    – D. Ben Knoble
    Commented Jul 14, 2021 at 18:17
  • 1
    Welcome to Vi and Vim! SSH will often mess with whitespace in your command line. Maybe try something like: ssh remotehost 'vim -c ":11" -c ":norm wllv,dZZ" myfile', in other words, put the whole remote vim command inside single quotes and then use extra double quotes for the arguments to -c? Not sure that's the exact invocation you need, but start there and experiment until you find the one that works...
    – filbranden
    Commented Jul 14, 2021 at 19:03
  • 1
    does it matter if you use vim -c ":11" -c ":norm wllv,dZZ" myfile Commented Jul 14, 2021 at 19:03
  • 2
    Just spitballin' here but I'd try this (all on the remote system): put your command in a file, say "test.sh" and run it with bash test.sh. If you get the same result dump it's bytes with xxd test.sh, share it via pastebin or add it to your question here....that'll allow checking for any funky/unexpected characters (perhaps due to some over-the-wire encoding issue).
    – B Layer
    Commented Jul 14, 2021 at 20:19

1 Answer 1

2

Your vim in your system is a wrapper script that includes a bug that will essentially discard any whitespace in the arguments and re-parse the arguments again.

The problem is the use of $*, which simply expands the arguments and lets the shell parse them again, without keeping track of which word was which original argument.

You can fix that wrapper script by changing it to:

if [ $LOGNAME == "root" ]; then 
    # <some logic here for when it's run by root> 
else 
    /usr/bin/vim "$@"
fi

The important part here being the use of "$@" (including the double quotes!) to ensure that the arguments are kept intact.

(BTW, you might want to also change that line to exec /usr/bin/vim "$@", which ensures the wrapper script is replaced by the vim program when that line is executed. That way if the process is killed with a signal, the signal will go to the Vim binary and not to the shell running the wrapper script.)

3
  • 1
    sigh classic sysadmin mistake. Why this logic is needed is beyond me, but there it is. I prefer sudoedit for root editing though.
    – D. Ben Knoble
    Commented Jul 14, 2021 at 23:17
  • 1
    If you prefer to avoid the script, you could adjust your path so /usr/bin comes earlier, or set EDITOR and VISUAL to /usr/bin/vim and invoked vim through those
    – D. Ben Knoble
    Commented Jul 15, 2021 at 11:29
  • 1
    Thank you so much @filbranden ! Since I can't edit the wrapper function, I just aliased vim to run /usr/bin/vim and I submitted a bug report to the sys admins. :)
    – awho
    Commented Jul 15, 2021 at 14:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.