* Possible vim bug @ 2020-12-07 18:06 Eric Connor 2020-12-07 21:57 ` Gary Johnson ` (2 more replies) 0 siblings, 3 replies; 7+ messages in thread From: Eric Connor @ 2020-12-07 18:06 UTC (permalink / raw) To: cygwin Hello, I have been experiencing an issue where I’m trying to format columns in vim using: :*%!column –t*, which had been working great. At some point I had to update Cygwin, and (not correlating it to a possible update issue, until recently) found that this command has been returning “shell returned 127” error. Today, I tested whether this command would work on a server (with a version of mlos), and found that it worked. The version of vim on my server is considerably older than my Cygwin version: Server: 7.4 Local: 8.2 Is there a way to either back-rev vim further (if an old install repo existed, that would be ideal), or someone review what was updated to make vim not happy with the column command? I also compared both versions of the column command, and they were the same on both my server *and* my local workstion...thus my conclusion that this seems to be a vim-related matter. I was successful in back-reving to 8.1, simply because I had the previous setup file for Cygwin, but older versions are a bit more difficult to locate...and I'm doubtful that going back much further wouldn't cause damage to my current setup. Thank you, Eric Connor ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible vim bug 2020-12-07 18:06 Possible vim bug Eric Connor @ 2020-12-07 21:57 ` Gary Johnson 2020-12-08 3:25 ` Kevin Schnitzius 2020-12-08 13:07 ` Brian Inglis 2 siblings, 0 replies; 7+ messages in thread From: Gary Johnson @ 2020-12-07 21:57 UTC (permalink / raw) To: cygwin On 2020-12-07, Eric Connor via Cygwin wrote: > Hello, > > I have been experiencing an issue where I’m trying to format columns in vim > using: :*%!column –t*, which had been working great. > > At some point I had to update Cygwin, and (not correlating it to a possible > update issue, until recently) found that this command has been returning > “shell returned 127” error. > > Today, I tested whether this command would work on a server (with a version > of mlos), and found that it worked. > > The version of vim on my server is considerably older than my Cygwin > version: > > Server: 7.4 > Local: 8.2 > > Is there a way to either back-rev vim further (if an old install repo > existed, that would be ideal), or someone review what was updated to make > vim not happy with the column command? > > I also compared both versions of the column command, and they were the same > on both my server *and* my local workstion...thus my conclusion that this > seems to be a vim-related matter. > I was successful in back-reving to 8.1, simply because I had the previous > setup file for Cygwin, but older versions are a bit more difficult to > locate...and I'm doubtful that going back much further wouldn't cause > damage to my current setup. I just tried this on a fresh install of Cygwin on Windows 10 and it worked fine. $ vim -N -u NONE :r!ls -l 13 more lines :%!column -t 14 lines filtered :echo v:shell_error 0 I assumed that the asterisks in your example command were some sort of formatting artifact. In the shell I ran "cygcheck -cd" and found the following versions: cygwin 3.1.7-1 vim 8.2.0486-1 vim-common 8.2.0486-1 vim-doc 8.2.0486-1 vim-minimal 8.2.0486-1 util-linux 2.33.1-2 bash 4.4.12-3 Util-linux is the package containing column. So I don't see a bug at all. Regards, Gary ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible vim bug 2020-12-07 18:06 Possible vim bug Eric Connor 2020-12-07 21:57 ` Gary Johnson @ 2020-12-08 3:25 ` Kevin Schnitzius 2020-12-08 13:07 ` Brian Inglis 2 siblings, 0 replies; 7+ messages in thread From: Kevin Schnitzius @ 2020-12-08 3:25 UTC (permalink / raw) To: cygwin, Eric Connor On Monday, December 7, 2020, 01:06:38 PM EST, Eric Connor via Cygwin <cygwin@cygwin.com> wrote: > At some point I had to update Cygwin, and (not correlating it to a possible > update issue, until recently) found that this command has been returning > “shell returned 127” error. ~ >asdfasdf-bash: asdfasdf: command not found~ >echo $? 127 I believe 127 is command not found. Kevin ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible vim bug 2020-12-07 18:06 Possible vim bug Eric Connor 2020-12-07 21:57 ` Gary Johnson 2020-12-08 3:25 ` Kevin Schnitzius @ 2020-12-08 13:07 ` Brian Inglis 2020-12-08 19:04 ` Eric Connor 2 siblings, 1 reply; 7+ messages in thread From: Brian Inglis @ 2020-12-08 13:07 UTC (permalink / raw) To: cygwin; +Cc: Eric Connor On 2020-12-07 11:06, Eric Connor via Cygwin wrote: > I have been experiencing an issue where I’m trying to format columns in vim > using: :*%!column –t*, which had been working great. > > At some point I had to update Cygwin, and (not correlating it to a possible > update issue, until recently) found that this command has been returning > “shell returned 127” error. > > Today, I tested whether this command would work on a server (with a version > of mlos), and found that it worked. > > The version of vim on my server is considerably older than my Cygwin > version: > > Server: 7.4 > Local: 8.2 > > Is there a way to either back-rev vim further (if an old install repo > existed, that would be ideal), or someone review what was updated to make > vim not happy with the column command? > > I also compared both versions of the column command, and they were the same > on both my server *and* my local workstion...thus my conclusion that this > seems to be a vim-related matter. > > I was successful in back-reving to 8.1, simply because I had the previous > setup file for Cygwin, but older versions are a bit more difficult to > locate...and I'm doubtful that going back much further wouldn't cause > damage to my current setup. Probably little to do with vim, mostly to do with either Cygwin Setup or PATH, so check the below and your PATH, your PATH within vim, and your Cygwin Setup logs: $ uname -srvmo CYGWIN_NT-10.0 3.1.7(0.340/5/3) 2020-08-22 17:48 x86_64 Cygwin $ which column /usr/bin/column $ cygcheck -f /usr/bin/column util-linux-2.33.1-2 $ cygcheck -c util-linux Cygwin Package Information Package Version Status util-linux 2.33.1-2 OK $ which vim /usr/bin/vim $ cygcheck -c vim Cygwin Package Information Package Version Status vim 8.2.0486-1 OK $ echo $PATH $ vim +'echo $PATH' $ vim +'!which column' /usr/bin/column Press ENTER or type command to continue $ l /var/log/setup.log* /var/log/setup.log /var/log/setup.log.full and it may be worthwhile rerunning Cygwin Setup to install any patched or upgraded packages and clean up any issues. If you see anything you don't understand, please post the above commands and output, plus any other commands and questionable output, and follow the problem reporting guidelines below (copy and trim large files if possible, and attach as text). -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible vim bug 2020-12-08 13:07 ` Brian Inglis @ 2020-12-08 19:04 ` Eric Connor 2020-12-08 19:37 ` Brian Inglis 2020-12-08 20:41 ` Andrey Repin 0 siblings, 2 replies; 7+ messages in thread From: Eric Connor @ 2020-12-08 19:04 UTC (permalink / raw) To: cygwin Thanks all, > *$uname -srvmo* > > CYGWIN_NT-10.0 3.0.5(0.338/5/3) 2019-03-31 11:17 x86_64 Cygwin > > *$which column* > > /usr/bin/column > > *$cygcheck -f /usr/bin/column* > > util-linux-2.33.1-2 > > *$cygcheck -c util-linux* > > Cygwin Package Information > > Package Version Status > > util-linux 2.33.1-2 OK > > *$which vim* > > /usr/bin/vim > > *$cygcheck -c vim* > > Cygwin Package Information > > Package Version Status > > vim 8.2.0486-1 OK > I'm not at liberty to share my path, due to the sensitivity of my position, but it *does *include /usr/bin, and it's the second entry in the value. *$vim +'echo $PATH' * Properly imports the path into vim :) *$vim +'!which column'* Properly imports the path to column: /usr/bin/column *ls -lrt /var/log/setup.log*|awk -F ' ' '{print $6, $7, $8, $NF}'*May 26 2020 /var/log/setup.log.runXa27444 Dec 7 13:43 /var/log/setup.log Dec 7 13:43 /var/log/setup.log.full Note: As I indicated earlier, I have been able to go back previous versions (with no success), and subsequently was able to run the update and bring the version back to current. One good data example is the following, which I'd be curious if anyone else is able to sort using *:%!column -t* *On my local machine (v.8.2.0486-1) * Before - 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 After - *:%!column -t*shell returned 127 3 lines filtered *On one of my servers (v. 7.4)* Before - 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 After - 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 Thank you, Eric Connor ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible vim bug 2020-12-08 19:04 ` Eric Connor @ 2020-12-08 19:37 ` Brian Inglis 2020-12-08 20:41 ` Andrey Repin 1 sibling, 0 replies; 7+ messages in thread From: Brian Inglis @ 2020-12-08 19:37 UTC (permalink / raw) To: cygwin [-- Attachment #1: Type: text/plain, Size: 4550 bytes --] On 2020-12-08 12:04, Eric Connor via Cygwin wrote: >> *$uname -srvmo* >> CYGWIN_NT-10.0 3.0.5(0.338/5/3) 2019-03-31 11:17 x86_64 Cygwin >> *$which column* >> /usr/bin/column >> *$cygcheck -f /usr/bin/column* >> util-linux-2.33.1-2 >> *$cygcheck -c util-linux* >> Cygwin Package Information >> Package Version Status >> util-linux 2.33.1-2 OK >> *$which vim* >> /usr/bin/vim >> *$cygcheck -c vim* >> Cygwin Package Information >> Package Version Status >> vim 8.2.0486-1 OK > I'm not at liberty to share my path, due to the sensitivity of my position, > but it *does *include /usr/bin, and it's the second entry in the value. What is the first entry and where does it point? > *$vim +'echo $PATH' * > Properly imports the path into vim :) > *$vim +'!which column'* > Properly imports the path to column: /usr/bin/column > > *ls -lrt /var/log/setup.log*|awk -F ' ' '{print $6, $7, $8, $NF}'*May 26 > 2020 /var/log/setup.log.runXa27444 > Dec 7 13:43 /var/log/setup.log > Dec 7 13:43 /var/log/setup.log.full $ ls -glort will skip the ids. > Note: As I indicated earlier, I have been able to go back previous versions > (with no success), and subsequently was able to run the update and bring > the version back to current. > > One good data example is the following, which I'd be curious if anyone else > is able to sort using *:%!column -t* > > *On my local machine (v.8.2.0486-1) > * > > Before - > > 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, > 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, > 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, > 0.00191202, 0.0134425 > 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, > 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, > 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, > 0.00339737, 0.00166596, 0.00451926, 0.00455153 > 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, > 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, > 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, > 0.000750669, 0.00230171, 0.00217917 > > After - > > > *:%!column -t*shell returned 127 > 3 lines filtered > > *On one of my servers (v. 7.4)* > > Before - > > 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, > 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, > 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, > 0.00191202, 0.0134425 > 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, > 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, > 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, > 0.00339737, 0.00166596, 0.00451926, 0.00455153 > 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, > 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, > 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, > 0.000750669, 0.00230171, 0.00217917 > > After - > > 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, > 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, > 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, > 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 > 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, > 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, > 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, > 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 > 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, > 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, > 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, > 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 Would be better if you attached your input, as it is unclear if this is meant to be three or more lines: attached input and output for both. Your problem is that column is not being executed from within vim. What you type in vim should be ":%!column -t" in command mode. You also need to check whether you have a vim command named column or only an external executable: $ vim +':echo exists(":column")' 0 $ vim +':echo executable("column")' 1 -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada This email may be disturbing to some readers as it contains too much technical detail. Reader discretion is advised. [Data in binary units and prefixes, physical quantities in SI.] [-- Attachment #2: column-post.txt --] [-- Type: text/plain, Size: 933 bytes --] 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 [-- Attachment #3: column-pre.txt --] [-- Type: text/plain, Size: 933 bytes --] 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 [-- Attachment #4: column-post-3.txt --] [-- Type: text/plain, Size: 770 bytes --] 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 [-- Attachment #5: column-pre-3.txt --] [-- Type: text/plain, Size: 770 bytes --] 1.33570301776, 3.61194e-06, 7.24503e-06, -9.91572e-06, 1.25098e-05, 0.0102828, 0.010352, 0.0102677, 0.0103789, 0.00161604, 0.00167978, 0.00159998, 0.00182596, 0.0019804, 0.0133687, 0.010329, 0.00163437, 0.00191202, 0.0134425 1.34538754675, 3.3689e-06, 9.86066e-06, -9.12075e-06, 1.18058e-05, 0.00334344, 0.00342207, 0.00332897, 0.00345504, 0.00165532, 0.00170412, 0.00164234, 0.00441903, 0.00459294, 0.00449357, 0.00339737, 0.00166596, 0.00451926, 0.00455153 1.34808186291, -1.99011e-06, 6.53026e-06, -1.18909e-05, 9.52337e-06, 0.00158065, 0.00166529, 0.0015657, 0.0017022, 0.000740644, 0.00078635, 0.000730052, 0.00219736, 0.00238191, 0.00212762, 0.00163783, 0.000750669, 0.00230171, 0.00217917 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Possible vim bug 2020-12-08 19:04 ` Eric Connor 2020-12-08 19:37 ` Brian Inglis @ 2020-12-08 20:41 ` Andrey Repin 1 sibling, 0 replies; 7+ messages in thread From: Andrey Repin @ 2020-12-08 20:41 UTC (permalink / raw) To: Eric Connor, cygwin Greetings, Eric Connor! > I'm not at liberty to share my path, due to the sensitivity of my position, > but it *does *include /usr/bin, and it's the second entry in the value. If I were you, I'd remove /usr/bin from $PATH. $ echo "$PATH" | sed -Ee 's/\:/\n/g;' $HOME/bin /usr/local/sbin /usr/sbin /sbin /usr/local/bin /bin /c/Windows/system32 /c/Windows /c/Windows/System32/Wbem /c/Windows/System32/WindowsPowerShell/v1.0 /c/Program Files/WinRAR /c/Program Files/7-Zip /c/DrWeb /c/Programs/VirtualBox /c/usr/util /c/usr/ARH /c/Programs/Subversion/bin /c/Programs/PuTTY Rationale being that Cygwin programs deduce setup layout from the first start, and some programs make wild assumptions about directory layout. I've seen quite the behavior happening from crossing these two consequences, when Cygwin took /usr/ for the root of the installation, and one of the programs tried to find something under /usr/usr/include/. -- With best regards, Andrey Repin Tuesday, December 8, 2020 23:33:16 Sorry for my terrible english... ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2020-12-08 20:50 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-12-07 18:06 Possible vim bug Eric Connor 2020-12-07 21:57 ` Gary Johnson 2020-12-08 3:25 ` Kevin Schnitzius 2020-12-08 13:07 ` Brian Inglis 2020-12-08 19:04 ` Eric Connor 2020-12-08 19:37 ` Brian Inglis 2020-12-08 20:41 ` Andrey Repin
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).