the CLI should fail gracefully when tahoe: doesn't exist and no alias is specified #939
Labels
No Label
0.2.0
0.3.0
0.4.0
0.5.0
0.5.1
0.6.0
0.6.1
0.7.0
0.8.0
0.9.0
1.0.0
1.1.0
1.10.0
1.10.1
1.10.2
1.10a2
1.11.0
1.12.0
1.12.1
1.13.0
1.14.0
1.15.0
1.15.1
1.2.0
1.3.0
1.4.1
1.5.0
1.6.0
1.6.1
1.7.0
1.7.1
1.7β
1.8.0
1.8.1
1.8.2
1.8.3
1.8β
1.9.0
1.9.0-s3branch
1.9.0a1
1.9.0a2
1.9.0b1
1.9.1
1.9.2
1.9.2a1
LeastAuthority.com automation
blocker
cannot reproduce
cloud-branch
code
code-dirnodes
code-encoding
code-frontend
code-frontend-cli
code-frontend-ftp-sftp
code-frontend-magic-folder
code-frontend-web
code-mutable
code-network
code-nodeadmin
code-peerselection
code-storage
contrib
critical
defect
dev-infrastructure
documentation
duplicate
enhancement
fixed
invalid
major
minor
n/a
normal
operational
packaging
somebody else's problem
supercritical
task
trivial
unknown
was already fixed
website
wontfix
worksforme
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Reference: tahoe-lafs/trac-2024-07-25#939
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
When I do 'tahoe ls' on a fresh node, I get
If I create an alias, then try again, I get
I should probably see something like
or, perhaps better still, the CLI code could look in ~/.tahoe/private/aliases and choose one of those instead of requiring the 'tahoe' alias (failing gracefully with something like the message above if nothing is there, of course).
Here is a test that exercises the first case above and fails.
(whether or not we'd want to have a distinct test for having aliases none of which are called tahoe depends on how this is solved)
Attachment 939test.darcspatch.txt (2182 bytes) added
Other CLI commands process the alias in the same way as ls, though. Let's see how they do it.
(the 'tahoe-test' node has no aliases)
'tahoe backup'
'tahoe check'
'tahoe cp'
'tahoe get'
'tahoe manifest'
'tahoe mkdir'
'tahoe mv'
'tahoe put'
'tahoe rm'
'tahoe webopen'
So I guess this isn't specific to 'tahoe ls', but instead is something that relates to many CLI tools. I'm updating the summary accordingly.
'tahoe ls': fail gracefully when tahoe: doesn't exist and no alias is specifiedto the CLI should fail gracefully when tahoe: doesn't exist and no alias is specifiedI like the
error: no alias specified, and the default 'tahoe' alias doesn't exist.
message. I'd like it even better it we added a second line with instructions:To create one, use "tahoe create-alias tahoe"
.And yeah, some CLI commands make as much (or more) sense without an alias.. "tahoe mkdir", "tahoe put", "tahoe get" are frequently used with raw caps, either accepting or returning them. It's the commands that always require aliases that are in most need of this improved error message.
#681 was a duplicate for
tahoe ls
. I've kept this ticket because it is more general and has more information.I'm attaching a patch that I think fixes this, and a few other problems related to explicitly specified aliases that don't exist.
When you invoke a command with no alias when
tahoe:
doesn't exist, or with an explicit alias that doesn't exist, you'll see something like:or
Attachment 939.darcspatch.txt (15757 bytes) added
fixes for #939
I can't see any problems in the code.
In the tests patch:
"C:\Windows"
should be"C:\\Windows"
.cli/Ln/ln_with_nonexistent_alias
, notcli/Ln/ln_without_alias
.failUnlessIn
is sometimes"error"
, sometimes"error:"
, and sometimes"error: "
. Make it consistent.open
calls should use"wb"
for the mode.Also,
tahoe webopen
with no arguments currently raisesTypeError: object of type 'NoneType' has no len()
(#855). Either fix this, or add a TODO comment referencing #855 where the relevant test would be.Replying to davidsarah:
Oh, that was because I hadn't specified
--node-directory
(which is a separate bug).What is relevant to this ticket is that the tests should include
test_webopen_without_alias
.Thanks for the review.
So I'm clear: have you found a way to break
tahoe webopen
that is (or should be) fixed in this ticket, but isn't tested by my patches? Or is there some other reason that you'd like to see the test there?Unless I'm mistaken, there should only be two backslashes in "C:\Windows", not four.
No (I thought I had, but I was mistaken). There is currently no test for
tahoe webopen
without arguments, but I'll leave it up to you whether you want to fix that in this ticket.Replying to davidsarah:
You're right -- I interpreted your comment as meaning that C:\ in a Windows path has two slashes, and I typed 4 to deal with escaping. But you meant that I literally should replace that string in the code with
C:\\Windows
. I'll fix that -- thanks.I think it would be more appropriate to add it when #855 is fixed. It's helpful to have something that is broken when writing a test -- that way, you have something well-defined to test for.
Attachment 939tests.darcspatch.txt (19415 bytes) added
tests for #939 -- review this one
Looks good.
fixed by changeset:63c8c6574745374a and changeset:c00a62a2e78a9b33. Thanks!