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

Strangely, "source <(...)" in .envrc doesn't work with my Bash v3.2.57 #52

Closed
bgandon opened this Issue Nov 9, 2017 · 15 comments

Comments

Projects
None yet
6 participants
@bgandon
Copy link
Contributor

bgandon commented Nov 9, 2017

When I go into the bucc project for the first time, then direnv allow doesn't modify the PATHenvironment variable:

$ git clone https://github.com/starkandwayne/bucc.git
...
$ cd bucc/
$ direnv allow
direnv: loading .envrc

Whereas if I just put eval "$(./bin/bucc env)" in .envrc then it works:

$ echo 'eval "$(./bin/bucc env)"' > .envrc
$ direnv allow
direnv: loading .envrc
direnv: export ~PATH

I didn't test this with the ${vars_store} file being present yet.

But anyway, maybe you should just simplify your .envrc and just leave eval "$(./bin/bucc env)" for both bash and zsh, don't you think?

Cheers,
/Benjamin

@krasio

This comment has been minimized.

Copy link

krasio commented Nov 9, 2017

Hi there,

I see the same issue (macOS Sierra 10.12.6, Terminal 2.7.3, Bash 3.2.57)

~/projects$ cd bucc/
direnv: loading .envrc
~/projects/bucc [master]$ echo $BOSH_ENVIRONMENT

~/projects/bucc [master]$

If I switch to eval "$(./bin/bucc env)" for bash in .envrc it exports all the ENV vars, but all of BOSH_CA_CERT is on a single line, which is causing issues.

~/projects/bucc [master]$ echo $BOSH_ENVIRONMENT
192.168.50.6
~/projects/bucc [master]$ echo $BOSH_CA_CERT
-----BEGIN CERTIFICATE----- MIIDEzCCAfugAwIBAgIQBl9j942cZLLl34bGT9yJcTANBgkqhkiG9w0BAQsFADAz MQwwCgYDVQQGEwNVU0ExFjAUBgNVBAoTDUNsb3VkIEZvdW5kcnkxCzAJBgNVBAMT AmNhMB4XDTE3MDgzMDA5MDM0N1oXDTE4MDgzMDA5MDM0N1owMzEMMAoGA1UEBhMD VVNBMRYwFAYDVQQKEw1DbG91ZCBGb3VuZHJ5MQswCQYDVQQDEwJjYTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALq0aVrWma1rye8YYoAE60KZsDuaZzoH 7caVtUAO2rt9Q0WcwrDMgztQckWo9J7Ghqwgd6rno4O+j8um/r84sjY5SwqkMp6L h8xXFy9SdboY3UIPsjaohGMUNNh9wYDQrVBsDBdXmDT0ymJWNKa+Wp7nw4bKAM1L kmPSWWedvwNMEOILhePJYDqiYnihMgEhjcRqcYWmEwno8aRl3W/6wcCFhv1fiuL+ iTZyAyHIkGgTg9xVMZ3IoaValP9yUAAT34jcqb/aexM16UVdty5g2xCyB8dQqsoc qFLJk7qGoZj2RR55rik0s3+wuL/yXZ4lYbtukZSMRq5h6PNbPKFLb9MCAwEAAaMj MCEwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQFMAMBAf8wDQYJKoZIhvcNAQEL BQADggEBAIo/5HDcdnjKCQ8M+Y+wX8Q+mLhzdiz9mCOsPzpPJhAbZ6eHIelFpqRk r2sM4oVERYXYNU/T1LMtxqqIFPAzep2/COoot40XTF87rcvX9pda5SmMYZ0fGy/d /hWHK5fzMjYxdxEs1EMoXZBOBOCU3RsQ+aehls89jaUBRQiELUHWyaY+LnfObH/t aYUA4kUe+8553suxWOH31hwqX+a5nGDwZbKSUJmMMYaTJ8XdIAaM8ZmORdFAtA2q k66Ya/Grjd4a/GQ3zHCw2M7OtZl+N+NAL9UpxoCo/CoEWGH0JzC69msrmTJNJiNs KM/F0gCvhrOM9hTHf4tOs4Jrwtz14zw= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDIzCCAgugAwIBAgIQeWDvnbg2opJdajmjpxIyZDANBgkqhkiG9w0BAQsFADA7 MQwwCgYDVQQGEwNVU0ExFjAUBgNVBAoTDUNsb3VkIEZvdW5kcnkxEzARBgNVBAMT CkNyZWRIdWIgQ0EwHhcNMTcwODMwMDkwMzQ5WhcNMTgwODMwMDkwMzQ5WjA7MQww CgYDVQQGEwNVU0ExFjAUBgNVBAoTDUNsb3VkIEZvdW5kcnkxEzARBgNVBAMTCkNy ZWRIdWIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCgcwzvm0KM z2Ncgaf8PmoNM4uR+YbP6SKSqgZAsWVWGg5J+uyBrwMbo3JKhyphQDubqJn1D6Tn HM0ms4hJ1x4IDA/0ftvkOfXwJ3THL4BMcprtYQ/NjGZo47E4ztw+a1xLoSsDr04Y YXUsNunSoxcCSmg489sYLPH5dDNzGXFKYPAuCl5ltI/T2tfOqOVBoPlPmPD5ZQX1 hvB3YzLQ4V0BiWLT+r0yVkMc22ubxxtKl+hJ+vffRR7+OjK6nx5/czLY5of/Q+V7 z/iPR7esC8ouj8fUUdqNAA4Ty/38YTekcSw8S9a/l5URAC9ZKAAm5S/r6JgC7EKB BMvssvfxP77TAgMBAAGjIzAhMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTAD AQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAhpFlTiTMSUlGFimz6DSWQVFWdAQlMCoVZ qzSghlkylobGWXAETXwILxYzlDzGD3McMQyCOGwD8HPwsqGx3XQlx+qeUlQ9xmUt jCRmTYe8wTD3Ken5NWSxyplqR3noJEvnWNJ3dJLRWRf9+UyrbZ3k6f5KjCVFsskE SEJd8ygwaIU1huhfUCTgO6ZWWWqX/k48U9QfC4MEHwRXm4Yj+hrN8sG/Pxc5m1UJ qIYS2iWe5MEuflA+ZZfqMj2Z7z6qaGOl6h3Dc8Hd9iLog0DvOudiwduW2Ls2QCK6 kgXPYLtFIVFczsAcb4mrbyJ325f8Kjj3SEvzWEqQ2U+lVUkMOruH -----END CERTIFICATE-----

So far my workaround is to dump output of ./bin/bucc env into a file and source it.

@norman-abramovitz

This comment has been minimized.

Copy link
Contributor

norman-abramovitz commented Nov 10, 2017

Process substitution is a bash 4.X addition. We will look what we can do but your workaround is correct. You could also install a bash 4.X as well.

@drnic

This comment has been minimized.

Copy link
Member

drnic commented Nov 10, 2017

@krasio

This comment has been minimized.

Copy link

krasio commented Nov 10, 2017

Yeah, I love process substitution too and I think we have this in Bash 3, for example

$ wc <(cat /usr/share/dict/words)
  235886  235886 2493109 /dev/fd/63

I've read something that when you do source <() it happens in subprocess and once it's done you lose all these exports.

Anyway, thanks for the work on making Bosh and friends easier to start with, I'll keep to my workaround for now.

@norman-abramovitz

This comment has been minimized.

Copy link
Contributor

norman-abramovitz commented Nov 10, 2017

@krasio @bgandon

Can one of you try the following code in your .envrc file and let me know if it solves the issue?
Thanks

case $SHELL in
*zsh)
eval "$(./bin/bucc env)"
;;
*bash)
source /dev/stdin <<<"$(./bin/bucc env)"
esac

@bgandon

This comment has been minimized.

Copy link
Contributor Author

bgandon commented Nov 10, 2017

Well, this seems even more complicated and I'm sorry, I didn't get the reason for such complication...

For which reason should we not do as eval "$(./bin/bucc env)" with Bash? In my case it works.

@norman-abramovitz

This comment has been minimized.

Copy link
Contributor

norman-abramovitz commented Nov 10, 2017

I ran into issues where eval would fail with multiline input and needing to do escaping all over the place where this approach does not.

This was one of workarounds where process substitutions fails with builtin commands.

@bgandon

This comment has been minimized.

Copy link
Contributor Author

bgandon commented Nov 10, 2017

Ok, I didn't test eval in the multi-line case indeed.

In the end, source /dev/stdin <<<"$(./bin/bucc env)" is very slow, but it works for me!

@norman-abramovitz

This comment has been minimized.

Copy link
Contributor

norman-abramovitz commented Nov 10, 2017

thanks. I know the original code (source using process substitution) seemed slow as well. At least I know I have a valid working case to compare to.

@rkoster

This comment has been minimized.

Copy link
Member

rkoster commented Nov 13, 2017

maybe it's time to add tests for this, because I don't know what we will break when we change this..

@norman-abramovitz

This comment has been minimized.

Copy link
Contributor

norman-abramovitz commented Nov 16, 2017

We can always do it the long way which is probably clearer to everyone. Both previous syntax styles just hides the temporary file.

bucc env >| tempfile
source tempfile
rm tempfile

@krasio

This comment has been minimized.

Copy link

krasio commented Mar 23, 2018

I realise how late this is answer is, sorry for that, but looks like source /dev/stdin <<<"$(./bin/bucc env)" is working fine for me.

@dbeauregard

This comment has been minimized.

Copy link

dbeauregard commented Jan 29, 2019

Same issue here with OSX 10.14.1 and Bash 3.2.57. source /dev/stdin <<<"$(./bin/bucc env)" seems to be working.

@norman-abramovitz

This comment has been minimized.

Copy link
Contributor

norman-abramovitz commented Jan 29, 2019

Thanks for the feedback. We will go ahead and finalize the long term solution.

@rkoster

This comment has been minimized.

Copy link
Member

rkoster commented Jan 30, 2019

On OSX Bash 3.2.57 for me both source /dev/stdin <<<"$(./bin/bucc env)" and eval "$(./bin/bucc env)" work equally well.
About the newlines in BOSH_CA_CERT, please make sure to use quotes when echoing, for example:

echo $BOSH_CA_CERT
-----BEGIN CERTIFICATE----- MIIEUzCCArugAwIBAgIQArEc4J1BWANXzcxwwVDh2jANBgkqhkiG9w0BAQsFADAz MQwwCgYDVQQGEwNVU0ExFjAUBgNVBAoTDUNsb3VkIEZvdW5kcnkxCzAJBgNVBAMT AmNhMB4XDTE4MDkxOTA3NTMwMloXDTE5MDkxOTA3NTMwMlowMzEMMAoGA1UEBhMD VVNBMRYwFAYDVQQKE.....

echo "$BOSH_CA_CERT"
-----BEGIN CERTIFICATE-----
MIIEUzCCArugAwIBAgIQArEc4J1BWANXzcxwwVDh2jANBgkqhkiG9w0BAQsFADAz
MQwwCgYDVQQGEwNVU0ExFjAUBgNVBAoTDUNsb3VkIEZvdW5kcnkxCzAJBgNVBAMT
AmNhMB4XDTE4MDkxOTA3NTMwMloXDTE5MDkxOTA3NTMwMlowMzEMMAoGA1UEBhMD
VVNBMRYwFAYDVQQKEw1DbG91ZCBGb3VuZHJ5MQswCQYDVQQDEwJjYTCCAaIwDQYJ
KoZIhvcNAQEBBQADggGPADCCAYoCggGBAKRKoc+UTa7PfdlAjpft4jN85HesE+SB
CotEYnJvOtKWgDkFwX4hEha1ug5/74Qwbim47S8Uq2i8xH+Vexp+T/eZPPI8KMq/
...

@rkoster rkoster added this to the v0.7.0 milestone Feb 7, 2019

@rkoster rkoster closed this in f1f609a Feb 7, 2019

ramonskie added a commit that referenced this issue Feb 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.