Running the binary against a non-existent pier name creates a new comet instead of complaining about vere

[joemfb]

@barter-simsum this behavior long pre-dates me. I think it was part of an early "just boot a comet and play around" onboarding push. -c is actually just a boolean flag ("create a new pier"), other things also toggle the same flag (-w, for instance). The pier name is an optional positional argument, set to the ship name if unspecified... The command-line arguments need plenty of cleanup -- lots of surprises and strangeness.

[tinnus-napbus]

@joemfb has there been any progress on this?

[tinnus-napbus]

should just fail if the pier doesn't exist and require -c to boot a comet

[zalberico]

@jalehman @vvisigoth - this is a pretty annoying one that should be an easy fix (though this issue probably now belongs in the vere repo).

[barter-simsum]

This seems to have been an intentional change ("make -c optional") introduced by @joemfb at some point. Joe, what do you think of requiring -c rather than implicitly creating a comet when the pier directory doesn't exist.

vere/pkg/vere/main.c

Line 464 in 17c14ac

// make -c optional, catch invalid boot of existing pier

964a86e

[zalberico]

I've seen this behavior confuse users - they try to boot with their patp and don't understand what they're doing, they end up with a directory of a comet named after their patp which is very confusing for them (and us when they ask for help). This is despite it outputting text about booting a comet.

Or they try to use pack but get the command args in the wrong order and it starts a comet instead.

We should error out in this case or at a minimum require a Y/N interaction, but I think erroring is preferred.

[tacryt-socryp]

I would far prefer error behavior rather than implicit pier generation

[barter-simsum]

I agree. Booting a comet when a pier doesn't exist is strange behavior. But I'd like to know why it was introduced in the first place and if it's being used to prevent something else bad from occurring.

[zalberico]

Cool - sounds like we're good to fix this. When we do we'll want to be careful about how we do it and communicating it loudly. Anyone that has scripts making assumptions based on current argument behavior could be affected depending on the change and how they're using it.

[zalberico]

Changing this behavior would be a nice (easy?) win if we could get it into an upcoming release

[jalehman]

@zalberico It'll happen soon. @barter-simsum are you working on this? Or are we searching for a newer contributor to grab this one @vvisigoth?

[zalberico]

Bumping this one as it come up in UC: Help again. @jalehman can we get this in the next release?

[jalehman]

Short answer: Maybe.

Long answer: @barter-simsum is on it just as soon as he finishes his work on the 8gb loom, which takes priority. Bandwidth for this will depend on what comes up in testing. Last we spoke about it he had seemed to think that this was a fairly straightforward solution, so I'm confident it'll happen soon.

[zalberico]

Cool, thanks!

[zalberico]

This already merged, but it’d be good to show usage on failure.

Often I’m trying to pack with loom 32 and get the arg order wrong and it starts trying to create a comet. An example on error of arg ordering would be good, but this is still way better than creating a comet (thanks).