CMD via -c Flag is not executed if the file doesn't already exist about openvi

[johnsonjh]

Yeah, let me think on this for a bit, I'll decide on something to try out, but in the meantime, I hope the patch above might work for you locally, if you want the new behavior.

[johnsonjh]

@Invarianz Thanks for the report.

I tested and can confirm this behavior.

This behavior seems to be intentional. Generally, I try to make sure that any changes to OpenVi don't conflict with any behaviors of POSIX vi or OpenBSD vi - but I do fix obvious bugs (and report them upstream, and also check to see if they're present in nvi2).

In this case, this behavior is specified by POSIX vi and OpenBSD vi. The -c option in nvi is described historically as execute commands after config and first file, which I would read as "after the configuration is processed, and after the first file is read". That's the wording the Vim keeps for this option's short help too. Since there is no "first file" read, the -c commands aren't executed.

The OpenVi (and OpenBSD vi) documentation says:

-c cmd    Execute cmd on the first file loaded.  Particularly useful for
          initial positioning in the file, although cmd is not limited to
          positioning commands.  This is the POSIX 1003.2 interface for
          the historic "+cmd" syntax.  nex/nvi supports both the old and
          new syntax.

The POSIX documentation seems to be more explicit (*emphasis* mine):

If the -c option was specified, the first time a file *that already exists*
(including a file that might not exist but for which recovery information is
available, when the -r option is specified) *replaces or initializes the
contents of the edit buffer*, the current line shall be set to the last line
of the edit buffer, the current column shall be set to non- <blank>, and the
ex commands specified with the -c option shall be executed.

In this case, the current line and current column shall not be set as
described for the command associated with the replacement or initialization
of the edit buffer contents. However, if the -t option or a tag command is
associated with this action, the -c option commands shall be executed and
then the movement to the tag shall be performed.

That all being said, I don't think your use is the norm, but I don't think it's too crazy, so, what to do?

I see that Vim solves this by adding a --cmd command that does what you want to do, but I'm not sure that's something that upstream would want, since historically vi doesn't use any long options.

I propose one of the following:

1. Adding a -C cmd option that does what you want. We'd have to decide if a new -C option should work independently of the existing -c option. Traditionally in nvi, for unknown historical reasons, -c is only accepted once (though comments in the source code indicate that could change.) So, we'd have to decide if -C and -c together should be valid or not. I'd say no, just to stick closest to existing historical behaviors, but I'm not sure yet.

2. Adding a new configuration option, off by default, maybe called fcinit (short option fc), since it is changing the file_cinit function's historical behavior to make -c work the way that Vim's --cmd does. This could be enabled by your .(n)exrc file (i.e. set fcinit) or via the command line with -C, so things would work the way you wanted by changing your invocation to:

ovi -Cc 'set wraplen=80' ~/hello.sh

In the meantime, if you really want to change the behavior of -c now, it's trivial to do make it work as you'd prefer with this patch, as a temporary workaround:

diff --git a/common/exf.c b/common/exf.c
index d8f26e3..6ff9d38 100644
--- a/common/exf.c
+++ b/common/exf.c
@@ -555,21 +555,21 @@ file_cinit(SCR *sp)
          *    If the file has previously been edited, move to the last known
          *        position, and check it for validity.
          *    Otherwise, move to the first line, first nonblank.
          *
          * This gets called by the file init code, because we may be in a
          * file of ex commands and we want to execute them from the right
          * location in the file.
          */
         nb = 0;
         gp = sp->gp;
-        if (gp->c_option != NULL && !F_ISSET(sp->frp, FR_NEWFILE)) {
+        if (gp->c_option != NULL) {
                 if (db_last(sp, &sp->lno))
                         return;
                 if (sp->lno == 0) {
                         sp->lno = 1;
                         sp->cno = 0;
                 }
                 if (ex_run_str(sp,
                     "-c option", gp->c_option, strlen(gp->c_option), 1, 1))
                         return;
                 gp->c_option = NULL;

Let me know what you think!

[johnsonjh]

Also, using + syntax with the proposed -C cmd or -C would introduce at least one small difference that could be annoying: positioning within the non-existing file would raise an error, for example, invoking ovi +5 nonexistent (or with -t set) would report something like:

-C option, 1: Illegal address: the file is empty

and we should decide if we should suppress this warning or not.

Edit: Thinking about it for more than a minute, I'd say no, simply because there are an infinite number of other ways to get an error with other ex commands, so I don't think special-casing the + option or -t makes sense.

Edit 2: fcinit / fc is probably a terrible name, because it's too close to filec and it doesn't make intuitive sense for anyone who doesn't look at the code. I'm open to suggestions for the option name, if we decide that is the best way to proceed.

[Invarianz]

Thanks for digging in the documentation and finding the exact wording. From a historical perspective this behavior makes sense now.

I really like the idea of an additional configuration option fcinit in .nexrc, maybe even keeping the original -c flag, without adding a new one.
However, it is possible that adding fcinit could break some exisiting functionality for people using -c as originally intended (no CMD execution when the file does not exist).
If they'd like to use the "old" functionality alongside with the new one, they'd need to set and unset fcinit, depending on the situation.

I have a possible idea that might solve this issue:
What do you think about adding the new -C flag with 100% the same behavior as -c.
However, if fcinit is additionally set, we get the new behavior only for -C. It should be clear from the documentation that certain vi & ex commands could fail when the option fcinit is set and -C is used.
This way we don't break existing implementations and have additional guard rails for people that only want to work with -C in the future.

I agree with the naming issue. Building on my proposal: What do you think about calling it something on the lines of ccompatible and having it true as a default, making -C 100% compatible with -c. For the ccompatible=false state, there should be an explanation on the man page mentioning exactly the historical explanation you just gave me.

[johnsonjh]

@Invarianz

I've decided to try what I think is the most simple route, adding a new -C cmd command, which will always execute cmd (after loading .{n}exrc startup files).

This new -C command is going to be mutually exclusive with -c.

(For various reasons, making these options have precedence introduced confusing rules, something I'd like to avoid, so I went with mutual exclusion.)

Just like -c, commands executed with -C start at the last line set, which is usually the last line, unless you start elsewhere, like using -t.

This means that -C creates an implicit conflict with the classic + behavior, because +100 is actually translated into -c 100. This means using -C wraplen=80 +100 actually means -C wraplen=80 -c 100.

If you really want to do something like that, you can use -C 'set wraplen=80|100'. Since you are launching your stuff from front-end scripts, you might want to do some shell magic to implement this + functionality accordingly.

This side effect behavior on the + command is unfortunate to me, but I'll keep it this way because nvi has always translated + commands into -c commands, so -c 'set wraplen=80 +100' would always have historically failed, and using +100 or -c 100 on a file that was non-existent would have always been a no-op, so I think it makes the most sense (or is at best the least confusing) to just make it so that the -C variant will fail in this case too.

This means that everything stays in line with the historical nvi/nex behaviors, such as for -c commands alone, like ovi -C cmd file, you start you out on the last line of the file, just like ovi -c cmd file would have done if the file exists.

Finally, an error messages will slightly change: only one -c command may be specified. will become only one -c or -C command may be specified.

Really, this write-up makes it all sound more complicated than it is. I'd appreciate if you give it a try and let me know how great or terrible this is. If nothing is too terrible, it'll become part of the next release.