-
Notifications
You must be signed in to change notification settings - Fork 75
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
feat: allow user to specify ssh or https access to an alternate site … #22
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,18 +5,26 @@ | |
|
||
set -e | ||
|
||
if [ "$#" -ne 1 ]; then | ||
if [ "$#" -lt 1 ]; then | ||
basher-help _clone | ||
exit 1 | ||
fi | ||
|
||
package="$1" | ||
package=$1 | ||
|
||
if [ -z "$package" ]; then | ||
basher-help _clone | ||
exit 1 | ||
fi | ||
|
||
site=${2:-github.com} | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What about There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Isn't that what's there? If you mean without "site=", then that would try to run "github.com" as a command, not set it as the default value. --edit: Oh I see, you mean the quotes. See my comment above. |
||
proto=https | ||
|
||
[[ $site == *@* ]] && { | ||
IFS=@ read -r login site <<< "$site" | ||
proto=ssh | ||
} | ||
|
||
IFS=/ read -r user name <<< "$package" | ||
|
||
if [ -z "$user" ]; then | ||
|
@@ -34,4 +42,6 @@ if [ -e "$BASHER_PACKAGES_PATH/$package" ]; then | |
exit 0 | ||
fi | ||
|
||
git clone --depth=1 --recursive "https://github.com/$package.git" "${BASHER_PACKAGES_PATH}/$package" | ||
[[ $proto == "ssh" ]] && repo=$login${login:+@}$site: || repo=$proto://$site/ | ||
|
||
git clone --depth=1 --recursive "$repo$package".git "${BASHER_PACKAGES_PATH}/$package" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This does not handle name collision, e.g. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't see that as a valid use case. Presumably they are the same project if they have the same name, and you wouldn't clone two separate copies in that case, instead you would clone from one and then add the other as a new remote. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
In most cases, but it is possible they are different, e.g. when both There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As you wish. |
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 think we can just keep
"$1"
here since users may give malformed input.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.
Assignments in bash don't do word splitting on variable expansions, quotes are only ever necessary if you use literal whitespace.
http://mywiki.wooledge.org/WordSplitting#Notes
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.
@binaryphile I prefer always quoting variable unless requiring token splitting and wildcard expansion. Because "users may give malformed input", e.g. I want to install
someone/program8
, but I mistyped8
to*
,basher install 'someone/program*'
and it happens there is a directorysomeone/program-sth
, then basher will installprogram-sth
. without any error. But if$1
is quoted, basher will try to installsomeone/program*
and fails with some meaningful error message.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.
Wildcard expansion is not performed either for assignments.
e.g.:
"declare -p" shows you the statement which generates the current contents of the variable. As you can see, "*" was not expanded prior to assignment, otherwise the contents of var_one would have been the directory listing of the current directory.
So if $1 contained a pattern, it would not be expanded as you were worried about:
As you can see, no expansion due to assignment.
In any case, it's fine to quote anyway, and I used to, it's just not my style any more. Do as you like.
--edit: just to be clear, I'm not disagreeing with quoting variables when using them, absolutely you should! I've just learned that it's not strictly necessary with assignments so I leave them off there. You can also leave them off the subject of case statements and inside [[ ]] tests. In general, you should use shellcheck with vim and it will tell you when quoting is important, which is nice.