-
-
Notifications
You must be signed in to change notification settings - Fork 3k
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
Add t0130-swarm.sh
#948
Add t0130-swarm.sh
#948
Conversation
IFS='' read -r line || [[ -n $line ]] || return | ||
grep $'^\t/[^/]*/[^/]*/[^/]*/[^/]*$' <<<"$line" >/dev/null || return | ||
done | ||
done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
While this may work, it's confusing and hard to edit. It may be better to do what other things do, and compare the actual output to an expected output.
Addresses may be tricky, because interfaces differ, but can check for 127.0.0.1
.
Another approach still may be the check the json output.
by the way, we can have dedicated programs in other languages that check these outputs, so doesn't have to be in sh
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this uses a lot of bashisms like <<<"$line"
while others tests should work with a lot of POSIX compatible shells.
Also cat <<<"$line"
looks a bit overengineered compared to just echo "$line"
:-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also cat <<<"$line" looks a bit overengineered compared to just echo "$line" :-)
I do agree :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What language should I use? If everyone's gonna use their favorite language to write test helpers, the code base will inevitably become an unrecognizable mess.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jbenet @kkoroviev my opinion about languages is that we should not require too many of them to test go-ipfs. And about shells I think it is better to try to be compatible with many POSIX compatible shells, so that ipfs scripts should not be too difficult to port to embeded or unix like systems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree wholeheartedly with @chriscool
We should stick to POSIX for shells.
There are some tests where it may become easier to test things with tools written in Go. Go is good enough, multi platform, really easy to work with (tooling), and already required for the project. So perhaps we can:
- default to do everything with
sh
- for convoluted things where a small go tool can really help, try go. but still compile it down to a unixy tool to be put into a sharness test.
- for now, no other languages-- as it might introduce another dependency, which would be painful.
That's because of the aforementioned unnecessary bashisms. |
ping |
closing due to inactivity, please reopen as necessary note: all pull requests older than three weeks may be closed in an effort to keep our open pull requests more focused. |
Online tests for
ipfs swarm addrs
.