bash function ignoring dot for git clone command

Question

I am wrestling with a bash function that will not clone to current directory, it is making a project folder:

cloneproject() { git clone git@bitbucket.org:codyc54321/$1.git . ;}

I have the dot at the end, before semicolon, but running this within a directory named 'bookwormbuddy' makes it add a new project folder as if you ran clone without a dot:

me@pc:~/projects/bookwormbuddy$ cloneproject bookwormbuddy
Cloning into 'bookwormbuddy'...

Yet when I run the same command from terminal, it works as I'm used to:

me@pc:~/projects/bookwormbuddy$ git clone git@bitbucket.org:codyc54321/new_bookmarks.git .
Cloning into '.'...

I need this as I name projects different in storage for reasons. How can I make ubuntu respect the dot? Thank you

I hadn't, and that worked: `cloneproject() { git clone git@bitbucket.org:codyc54321/$1.git \. ;}`. Do you know what bash thought the dot was? Did it think it was a regex? You can answer if you want credit, thanks — codyc4321, Nov 30 '15 at 05:25
Yup. Look at [this SO article](http://stackoverflow.com/questions/6485767/bash-regex-gotcha) for confirmation. Check that it still runs correctly from the terminal. — Tim Biegeleisen, Nov 30 '15 at 05:27
@TimBiegeleisen That makes absolutely no sense, unless you want to clone into the directory named `\.`. @codyc4321 Note how the command that worked for you isn't want Tim suggested (he suggested `\\.`). And your `\.` is the same as `.`, because dot doesn't need quoting. Where are you defining the function? — 4ae1e1, Nov 30 '15 at 05:28
Well, Tim knew what I wanted to do. I am trying to say "clone this git thing into this directory, named '.' for convenience". The dot did need quoting because as it was before, it got ignored and did not clone to current directory (.) but cloned as normal, in a new dir named after the project — codyc4321, Nov 30 '15 at 05:33
Please show us the output of `type cloneproject`. (As I commented above and in the answer below, `.` shouldn't need quoting, so there's a problem somewhere else.) — 4ae1e1, Nov 30 '15 at 05:40
Continuing discussion from the answer below: if you switched to the new version, you'll see `type cloneproject` prints exactly the same output, meaning that the two function definitions are just the same. Now, you might want to run `set -x` in your command line to see what's really getting executed, but I doubt you'll get any insight from there. — 4ae1e1, Nov 30 '15 at 05:55
@4ae1e1 Can you think of any reason why the context in which the function is running treats `.` as a special character (and therefore escaping it has a special meaning) ? — Tim Biegeleisen, Nov 30 '15 at 05:57
@TimBiegeleisen No. As I said, `set -x`, and you'll see that it isn't treated as anything special. I bet the problem is with `git`, although I cannot reproduce in any setting. Ubuntu or not, same name or not, whatever. It just works, and there's no reason it shouldn't. — 4ae1e1, Nov 30 '15 at 05:59
@TimBiegeleisen By the way, there's even more proof that dot isn't treated as anything special: the OP even mentioned that if he/she ran the command directly on the command line, with unquoted `.`, if worked... — 4ae1e1, Nov 30 '15 at 06:11
@4ae1e1 Exactly. This is why I agree that the `git` command is doing something here. — Tim Biegeleisen, Nov 30 '15 at 06:12
@TimBiegeleisen That seems rather unlikely too. Because in the end the function should execute exactly the same command as the one directly executed on the command line (unless OP has some weird `IFS`, in which case he/she should get error messages). This is weird, and there's nothing we can do in this pursuit if OP doesn't want to pursue. Anyway, sorry about some of my stronger words earlier, but I do detest the attitude of leaving an answer unattended as soon as it's accepted, and taking offense in other's objections. — 4ae1e1, Nov 30 '15 at 06:24
You are leaving too many comments IMO. You got your point across a long time ago :-) — Tim Biegeleisen, Nov 30 '15 at 06:25

score 1 · Accepted Answer · edited May 23 '17 at 11:52

1

You can escape the dot to tell the Bash not to treat it as part of a regular expression:

cloneproject() { git clone git@bitbucket.org:codyc54321/$1.git \. ;}

As this SO post discusses, Bash will treat a single dot as meaning "any character."

edited May 23 '17 at 11:52

Community

1
1

answered Nov 30 '15 at 05:28

Tim Biegeleisen

502,043
27
286
360

they've got a 5 minute cooldown period to accept...is this buying a gun? ;) – codyc4321 Nov 30 '15 at 05:34
LOL not sure. For future reference, you should always keep escaping characters in the back of your head. This problem pops up in bash, regex, Java, Perl, and even SQL. – Tim Biegeleisen Nov 30 '15 at 05:35
Ya, it seems like I get burned 1000 times a year not escaping something, and I never learn :) – codyc4321 Nov 30 '15 at 05:36
1

This is just wrong (wrong in the sense that no improvement whatsoever). I don't know why the original version doesn't work (it should work, I even tested), but this is exactly equivalent to the original. This is NOT a regex setting, and `.` is not a wildcard (https://www.gnu.org/software/bash/manual/bash.html#Filename-Expansion). Please don't quote random things from different settings. – 4ae1e1 Nov 30 '15 at 05:38
@codyc4321 Please don't take the advice of always quoting the dot in bash, because that's just ridiculous. Unless I'm proven wrong later. – 4ae1e1 Nov 30 '15 at 05:39
@4ae1e1 I was giving general advice of escaping characters which may have a special meaning, that's all. – Tim Biegeleisen Nov 30 '15 at 05:40
@TimBiegeleisen Dot has no special meaning in bash, outside a regex, or as a shell builtin (`source`). None apply here. – 4ae1e1 Nov 30 '15 at 05:42
I'd love to learn more, but this answer immediately solved my problem on this machine. I'm using ubuntu. If the reason it fixed it is different, I'd love to know why, but it worked – codyc4321 Nov 30 '15 at 05:46
By the way, dot has another slightly special meaning: `*` won't match a dot at the beginning of a filename in filename generation. Still, that has nothing to do with the situation at hand. – 4ae1e1 Nov 30 '15 at 05:46
@codyc4321 If you want to find out why, the first step is to switch back to the version that did not work, and do `type cloneproject`, as I commented above. – 4ae1e1 Nov 30 '15 at 05:47
`cloneproject is a function cloneproject () { git clone git@bitbucket.org:codyc54321/$1.git . }` – codyc4321 Nov 30 '15 at 05:49
1

Would you all mind not making a mess on my answer? Thanks. – Tim Biegeleisen Nov 30 '15 at 05:50
He actually does have a point, the command works the old way when the folder I'm in matches the project name (autohelper and autohelper on bitbucket), but did not work when the names differed (bookwormbuddy vs new_bookmarks_tracker). Now I'm curious but it's getting late and the answer works for all use cases.. – codyc4321 Nov 30 '15 at 05:53
2

If commenting on a potentially wrong answer (and the reference definitely makes no sense, and the extraordinary claim `Bash will treat a single dot as meaning "any character."` is just hilarious, even if the answer has some value in some sense) to find out the real cause is making a mess, then sure. And you didn't address any of my legit concerns (you attitude seems to be harvest points and leave, seeing as you drew a reference that made no sense, then pressed for acception and upvote from me). Let's move the discussion to below the post. – 4ae1e1 Nov 30 '15 at 05:53
I don't know how to do that – codyc4321 Nov 30 '15 at 05:54

bash function ignoring dot for git clone command

1 Answers1