more issues with top

For reasons I don't understand, sometimes top displays the process command line as right-justified. Whenever it happens, all command lines are right-justified. Anyone have any ideas? It is a bug, albeit harmless. Cheers, Marty -- Problem reports: http://cygwin.com/problems.html FAQ:

[ATTN: procps maintainer] RealPageSize

This fix for php (posted by ricardohenry...@gmail.com) should be applied to the code for "top"; it (and /usr/bin/time -v) think the page size is actually 64k, and reports RESident size as 16 times what it should be. # if HAVE_UNISTD_H # include # if defined(_SC_PAGESIZE) +# ifdef __CYGWIN_

-bash: _fzf_orig_completion_g++: bad substitution

I get that message every time I open Cygwin (mintty). Not sure when it started happening, but could be as long as a month (or so) ago. --Marty -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.htm

git push fork for pack-objects fails, and takes more than 10 minutes to fail!

User@DESKTOP /cygdrive/z/mykif/sumo $ time git push Username for 'https://github.com': Password for 'https://u...@github.com': 0 [main] git 8936 child_info::sync: wait failed, pid 10664, Win32 error 0 105 [main] git 8936 fork: child -1 - forked process 10664 died unexpectedly, retry 0, ex

git commit can't fork for vi, and takes over 10 minutes to fail!

User@DESKTOP /cygdrive/z/mykif/sumo $ time git commit -a 0 [main] git 3576 child_info::sync: wait failed, pid 6788, Win32 error 0 96 [main] git 3576 fork: child -1 - forked process 6788 died unexpectedly, retry 0, exit code 0x1D29857, errno 11 error: cannot fork() for vi: Resource tempor

/usr/bin/time -v (or -f=%M) is 64 times what it should be

This is probably another page size/count miscalculation. I use that field for benchmarking, so it means adding a Cygwin-specific hack to make the scripts portable to other Posix systems. Cheers, Marty -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.

/usr/bin/top: RES and MEM% are 16 times VIRT

The RES column displayed by /usr/bin/top is 16 times as large as VIRT (as is MEM%, since it is presumably calculated from RES). From my observations, VIRT seems to agree with /proc/self/stat field 22 (0-origin), and matches what I expect. Not a big deal, but it surprised the heck out of me I