Local only repository - Mac OS X support

[scls19fr]

Hello,

gws doesn't seems to work correctly with Mac OS X 10.10

$ brew install bash

$ brew install gnu-sed

doesn't seems to fix it.

All repository inside my workspace are marked as

Clean [Local only repository]

or

Dirty (Uncached changes) [Local only repository]

These repositories are not only local!

Any idea ?

[kniren]

Are you sure you are running bash > 4?

You can check with

bash --version

[StreakyCobra]

Thanks for reporting. I confirm last version is using some GNU-sed specific flags.

I'm thinking about either:

• Updating the README to ask for GNU-sed installation; or
• Updating the code to avoid the usage of problematic flags.

Concerning the last problem, it's probably related to few cut commands using GNU-cut specific flags like --complement. Same concern here.

I'll investigate and think about all this.

[scls19fr]

$ bash --version
GNU bash, version 4.3.33(1)-release (x86_64-apple-darwin14.1.0)
Copyright (C) 2013 Free Software Foundation, Inc.
Licence GPLv3+ : GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

[scls19fr]

$ brew install coreutils
==> Downloading https://homebrew.bintray.com/bottles/coreutils-8.24.yosemite.bottle.tar.gz
######################################################################## 100,0%
==> Pouring coreutils-8.24.yosemite.bottle.tar.gz
==> Caveats
All commands have been installed with the prefix 'g'.

If you really need to use these commands with their normal names, you
can add a "gnubin" directory to your PATH from your bashrc like:

    PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"

Additionally, you can access their man pages with normal names if you add
the "gnuman" directory to your MANPATH from your bashrc as well:

    MANPATH="/usr/local/opt/coreutils/libexec/gnuman:$MANPATH"

I don't want to change default tools (sed, cut...) but that's probably possible to use GNU tools without affecting PATH.

[StreakyCobra]

Solutions so far:

• Updating the README to ask for installing coreutils and changing the $PATH accordingly
• Updating the README to ask for installing coreutils, modifying the code to switch to g-prefixed tools on OS X.
• Modifying the code to avoid using problematic coreutils options

@scls19fr: can you confirm the script is working with coreutils' version of sed and cut?

[scls19fr]

Yes after changing PATH it don't display "Local only repository" anymore

export PATH=$PATH:$HOME/gws

export PATH="/usr/local/opt/coreutils/libexec/gnubin:$PATH"
export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"

but I'd prefer a less intrusive solution

[StreakyCobra]

Ok thanks.

but I'd prefer a less intrusive solution

I can understand.

In the meantime you can define an alias in your .bashrc or .zshrc:

alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:$PATH gws"

which should do the work without requiring a system-wide update of $PATH.

[scls19fr]

I think it's

alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"

For many repo I get

"Dirty (Untracked files)"

How to cleanup this ?

[StreakyCobra]

I think it's alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"

Ok, I was thinking coreutils path was enough.

"Dirty (Untracked files)" How to cleanup this ?

This appears when there are files which are not followed by git, nor ignored by it. When you do a git status they are showed under "Untracked files:"

• If the files are needed for your project, they should be versionned by git
• If they are generated by your code, or not needed like local configuration files or whatever, they should be ignored to avoid being committed by mistake. To be ignored they needs to be listed in the .gitignore file. Look here for some language-specific starting point .gitignore.

[scls19fr]

Ok I will correct my .gitignore accordingly. Thanks

[StreakyCobra]

Could you try the version in the develop branch without GNU-coreutils?

Issues with OS X sed and cut should have been resolved.

[scls19fr]

I still need some git lessons.

$ git branch
* master

How to change to develop branch ?

[StreakyCobra]

Running:

$ git checkout develop

should be enough :-)

[Edit] Output should be something like:

Branch develop set up to track remote branch develop from origin.
Switched to a new branch 'develop'

[scls19fr]

I removed alias

alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"

First run

$ gws
The URL at position 3 for "OneOfRepository" is missing a name.

Running again

$ gws

returns nothing

[scls19fr]

Something odd happened...

After

$ git checkout master

and setting again alias

alias gws="PATH=/usr/local/opt/coreutils/libexec/gnubin:usr/local/opt/gnu-sed/libexec/gnubin:$PATH gws"

when I do:

$ gws

it doesn't returns anything anymore.

I also tried to remove .projects.gws

$ gws init
Workspace file «.projects.gws» created.

$ gws

returns nothing

Any idea ?

[StreakyCobra]

Hum, depressing :expressionless:

But trying to be positive: There are no more version-specific's errors.

To solve your problem: I implemented a cache system to speedup the execution by avoiding parsing every time the .projects.gws file. Cache is stored in the .cache.gws file. Just remove it and everything will get back to a working state.

[emlun]

On the feat/cross-platform branch the cut commands no longer use the GNU-specific --complement option. I don't have a Mac/BSD machine to try it on, though - would anyone (ping @JohanSpaedtke) mind testing if this now works on those platforms with default PATH?

[JohanSpaedtke]

Well I don't know if it works better than before but at least it's different :)

On master you'll get the following with default PATH

cut: illegal option -- -
usage: cut -b list [-n] [file ...]
       cut -c list [file ...]
       cut -f list [-s] [-d delim] [file ...]

On this feature branch you get the following instead

repo1:
                              Clean [Local only repository]
repo2:
                              Dirty (Uncached changes) [Local only repository]
repo3:
                              Clean [Local only repository]

But on master with a modified PATH you get

repo1:
    master :                  Clean
repo2:
    master :                  Dirty (Uncached changes) 
repo3:
    local-branch :           No remote branch origin/local-branch
    master :                  Clean

[emlun]

That's strange... I was hoping getting rid of --complement would solve it, but I guess there's more to it. I'm afraid I'll have to defer further investigation into this until I have a Mac/BSD box to test on.