Stephen Barker
Stephen Barker
`ddev ssh` should return the exit code that is returned from docker-compose and not add extra output
Okay. I see. I WAS using HEAD. But I had made the same changes as you had put in #1697 and then I saw #1697, assumed it was still in...
`ddev ssh` should return the exit code that is returned from docker-compose and not add extra output
I seem to have hit a chicken-egg problem. Theoretically, you could check in ssh.go if there are values being piped in, and if so, go ahead and return the error...
`ddev ssh` should return the exit code that is returned from docker-compose and not add extra output
Absolutely.
`ddev ssh` should return the exit code that is returned from docker-compose and not add extra output
NOTE: In addition to not solving the problem, `ddev ssh` "hangs" because it appears to be waiting for the stdin input read that was added. Weird.
`ddev ssh` should return the exit code that is returned from docker-compose and not add extra output
Also, just confirming that adding a `fmt.Println("pipedValues = ", pipedValues)` in there correctly outputs the piped in values (when piped in).
I ran into this, too, on Mac OS 10.11. I found you could run it via the command line as admin like so: sudo -b /PATH/TO/Vega.app/Contents/MacOS/Vega I stuck that into...
Oh. Okay, I misunderstood you. However, won't this create a functional disparity, e.g. spaces in variable names works in providers but doesn't in config.yaml, etc.? I obviously don't know the...
and 3. Add a notification if provider environment_variables are detected as you previously suggested?
I'd be aggressive too if I'd had to deal with those failing docker containers for as long as you. Hahaha But sounds like a plan. Will look to initiate this.
Can you provide more guidance on exactly what was meant by: > * Make all the provider integrations work without edits/copies/etc What should the warning message say? Here's a suggestion...