Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Section 1.5. Join the Network #170

Open
jurij-jukic opened this issue May 7, 2024 · 0 comments
Open

Section 1.5. Join the Network #170

jurij-jukic opened this issue May 7, 2024 · 0 comments
Assignees

Comments

@jurij-jukic
Copy link
Contributor

jurij-jukic commented May 7, 2024

https://book.kinode.org/login.html#starting-the-kinode
https://book.kinode.org/login.html#running-the-binary
The two of these give the code ./kinode home and ./kinode --help. And that's what I did. And I got zsh: permission denied because I was running it on the folder and not the binary. It says before the code snippets to run on the binary, but imo still not idiot proof. And there are also nested kinode folder which makes it confusing as well.
My suggestion is to have 2 separate subsections depending on where we are running the binary from. So one subsection would say ./kinode/kinode/target/debug/kinode home and the other ./Downloads/kinode home so it's painfully obvious where it needs to be run from.


Nick:
Yeah this is a fundamentally hard problem for giving directions. If we had a specific chain it would be better, e.g.
wget foo
unzip foo
cd foo/
./bar

but since there are multiple chains, I agree we'd have to specify different specific commands which I am hesitant to do because it gets messy. I wonder if there is some find or smth we can do to locate binary, assign to env var, then run, or something along those lines 🤔

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants