Fix (t)csh system call (from CheckCtags) stdout, stderr redirection

[awidegreen]

Create system-call 'cmd' to call sh -c "..." in order to internally call bash, in case (t)csh is used as default shell.

[xolox]

Can you explain the problem that you fixed? I don't use (t)csh and have no experience with it.

[xolox]

If you have configured tcsh as your log-in shell and this breaks Vim (plug-ins), why not simply change the value of Vim's 'shell' setting? I'm not sure my plug-ins (I) should be deciding which shell should be used by the users of my Vim plug-ins to execute commands ...

[awidegreen]

The problem is that tcsh can not redirect stderr and stdout separately. Furthermore, the syntax for redirecting stderr an stdout together in tcsh is done differently, i.e. ">&". I can agree that you shouldn't let your plugins decide on the executing shell, but then the bash-like redirecting style ("1>%s 2>%s") shouldn't be used either, don't you think?

Changing the shell setting can lead to issues when executing external scripts that are written in c-shell. That isn't a sufficient approach in my case.

However, I can agree that my fix is some dirty hack - a more generic would be nice.

[xolox]

The problem is that tcsh can not redirect stderr and stdout separately. Furthermore, the syntax for redirecting stderr an stdout together in tcsh is done differently, i.e. ">&". I can agree that you shouldn't let your plugins decide on the executing shell, but then the bash-like redirecting style ("1>%s 2>%s") shouldn't be used either, don't you think?

Fair enough, as I said I've never used (t)csh before so I'm not familiar with how it works. It surprises me to hear that it does not support separate redirection of standard output and standard error though! I suppose I can make my plug-ins compatible with (t)csh environments, I'm just afraid there's a dozen more shells with differing behaviors requiring separate workarounds at some point :-(

Changing the shell setting can lead to issues when executing external scripts that are written in c-shell. That isn't a sufficient approach in my case.

This I don't understand. Do you use shebang lines in your scripts? If not, why not? If so, don't the shebang lines take care of this?

[xolox]

I can agree that you shouldn't let your plugins decide on the executing shell, but then the bash-like redirecting style ("1>%s 2>%s") shouldn't be used either, don't you think?

This a quite fundamental feature for most of the Vim plug-ins I've written so it's not going away. This is the first ever bug report I got about (t)csh which shows it's a minority platform compared to sh compatible shells. I'm willing to accomodate (t)csh with special casing but I'm not removing the feature.

[awidegreen]

This I don't understand. Do you use shebang lines in your scripts? If not, why not? If so, don't the shebang lines take care of this?

Of course, you are right .. I realized that later. :)

This a quite fundamental feature for most of the Vim plug-ins I've written so it's not going away. This is the first ever bug report I got about (t)csh which shows it's a minority platform compared to sh compatible shells. I'm willing to accomodate (t)csh with special casing but I'm not removing the feature

Agreed. I normally don't use (t)csh either, expect in environments where I'm kind of forced to.

For the time being, I will give it a try with adjusting the 'shell' or stick with the current approach.

[xolox]

Hi Armin,

Because xolox#misc#os#exec() already expects to be able to separate standard output from standard error and I'm not willing to change this, I decided to go with the approach you suggested: hard coding the plug-in to use sh on UNIX (I cannot imagine any situation where sh would not be available, so it's probably not that big of a deal). I committed the change in f7ed989081e98df4eceaf21bc23197abeba332ef. Can you confirm that the latest version of the vim-easytags works out of the box for you? Thanks in advance!

- Peter

[awidegreen]

Works fine (using tcsh as login shell), thanks!

Cheers, Armin