Re: Unable to use Cygwin RCS commands in Windows Emacs
On Freitag, 22. September 2017 04:26:47 CEST David Standish wrote: > I managed to get windows emacs to work with cygwin rcs. > > Apart from rcs.exe, the other rcs commands are shell scripts that > invoke rcs.exe. > > Create a modified version of vc-rcs.el > replacing the various vc-do-command's with alternate ones that use > rcs.exe directly, > For example: > > (apply 'vc-do-command "*vc*" 0 "ci" file > > becomes > (apply 'vc-do-command "*vc*" 0 "rcs" file "ci" Thanks, David, that works great! My earlier attempt (apply 'vc-do-command "*vc*" 0 "rcs" "ci " file failed, but I should have done a "Describe-function: vc-do-command" first... Thanks again, Heinz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unable to use Cygwin RCS commands in Windows Emacs
Am Mittwoch, 20. September 2017, 23:01:48 CEST schrieb cyg Simple: > I suggest you ask your Windows Emacs support list. They would have the > most users with suggestions. Thanks, yes, will do. Regards, Heinz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Unable to use Cygwin RCS commands in Windows Emacs
Am Mittwoch, 20. September 2017, 22:40:53 CEST schrieb Brian Inglis: > > Tried creating shortcuts to the commands in $HOME/bin/, running > C:\Cygwin\bin\sh /bin/cmd %*, and adding $HOME/bin to the start of your > Windows PATH? Thanks, but that doesn't work. Emacs does not see shortcuts as executables. Regards, Heinz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Unable to use Cygwin RCS commands in Windows Emacs
At some point in history, /usr/bin/co, /usr/bin/ci, /usr/bin/rlog etc. turned from .exe into shell scripts, which are now wrappers for the main program /usr/bin/rcs.exe. However, these shell scripts can not be called directly from a Windows command line and moreover can not be invoked by a Windows (not Cygwin) Emacs (25.2 currentlly). Windows Emacs expects external Windows commands/binaries like co, ci, rlog, etc. to exist somewhere in the PATH. The commands to be invoked for version control with RCS are hardcoded into "C:\Program Files\emacs-25.2\share\emacs \25.2\lisp\vc\vc-rcs.el" and can not be customized, as far as I know. I tried to create wrapper scripts for Windows too (co.cmd, ci.cmd etc. - basically just "c:\cygwin\bin\bash -c '/bin/%~n0 %*'"), which work to some extend on the Windows command line, but mostly fail when invoked from Emacs' version control functions. The most recent native Windows port of RCS I could find is version 5.7 and dates back to 1999. In addition, it uses filenames like "RCS/somefile" instead of the usual "RCS/somefile,v", so this does not look like a way to go either. I'm clueless now. Does someone successfully use Cygwin's RCS commands in Windows Emacs? Is there still an older Cygwin RCS package around which contains "real" co.exe, ci.exe etc.? Any help is greatly appreciated. Heinz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server
Just for the records today's answer from HP support: --- 8 --- 8 --- Hi , I have a final respons from engineering for case . It appears that ASU is not doing anything wrong however NT4 is having a bug here, please read below for the explanation. But as we are claiming to be NT4 compatible this will be changed in the next major release. But as you allready have your solution via Cygwin we will work this out internally. Therefor I am informing you that this request will be closed. Kind regards, . Problem statement: -- mv command from Cygwin client executed on a file on an ASU share returns Access Denied error Analysis: - 1) In the 'NT Create AndX Request' the Cygwin client is sending an Access Request of 0x0001 Thereby requesting only for the DELETE access corresponding to 0x0001 Hence, this is the Access that gets granted to the Cygwin client from the ASU server side. 2) The next request, 'Query File Basic Info' is sent with a Granted Access of 0x0001 that was obtained in the previous 'NT Create AndX Request' This request fails with the error, 'STATUS_ACCESS_DENIED' as the client does not have the Desired Access to Query for the File Basic Info. For this request to have completed successfully, the Granted Access should have been 0x0080 which corresponds to Read Attributes Access Thus, the Cygwin client should have requested for a minimum Access of 0x00010080 in the first 'NT Create AndX Request' which is required for copying/moving/renaming files. Solution: - The code will need to be modified to grant the Cygwin client with the access 0x00010180 although the Access Requested for in the 'NT Create AndX Request' by the Cygwin client is 0x0001 As this includes 0x0080 which is the access required to Read Attributes the next request, 'Query File Basic Info' would complete successfully and hence the mv command from the Cygwin client would execute successfully. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server
Am 24.08.2010 18:28, schrieb Corinna Vinschen: RCS now works again (also in Windows Emacs), and so does a ~ 1300 lines script I'm currently working on. Is it safe to use this cygwin1-test2.dll for serious work? We are just preparing a new master image for several PCs and would like to include a working Cygwin 1.7. Please wait. I was hoping that you could test a little bit further. Sure. I prepared another DLL, which is very close to the real thing. There's another flag which I have to know if it's required or not. http://cygwin.de/cygwin-ug-177/cygwin1-test4.dll.bz2 (md5sum 889a86df2c2aafd010249b27bf10f411) If it works, we're finished. If not, we probably need just one more iteration. Test4 works, great. In the meantime, can you send the output of `mount' to this list? I would like to make sure that the drives are really recognized as cifs. Testing was done in /mnt/testperms with the following mounts in effect: $ mount //dlanserv/kramski$ on /mnt type cifs (binary,notexec,ihash,user) C:/cygwin/bin on /usr/bin type ntfs (binary,auto) C:/cygwin/lib on /usr/lib type ntfs (binary,auto) C:/cygwin on / type ntfs (binary,auto) C:/bin32 on /usr/local/bin type ntfs (binary) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) E: on /cygdrive/e type cifs (binary,posix=0,user,noumount,auto) F: on /cygdrive/f type cifs (binary,posix=0,user,noumount,auto) G: on /cygdrive/g type cifs (binary,posix=0,user,noumount,auto) H: on /cygdrive/h type cifs (binary,posix=0,user,noumount,auto) I: on /cygdrive/i type cifs (binary,posix=0,user,noumount,auto) J: on /cygdrive/j type cifs (binary,posix=0,user,noumount,auto) O: on /cygdrive/o type cifs (binary,posix=0,user,noumount,auto) P: on /cygdrive/p type cifs (binary,posix=0,user,noumount,auto) R: on /cygdrive/r type cifs (binary,posix=0,user,noumount,auto) S: on /cygdrive/s type cifs (binary,posix=0,user,noumount,auto) T: on /cygdrive/t type cifs (binary,posix=0,user,noumount,auto) W: on /cygdrive/w type cifs (binary,posix=0,user,noumount,auto) X: on /cygdrive/x type cifs (binary,posix=0,user,noumount,auto) Y: on /cygdrive/y type cifs (binary,posix=0,user,noumount,auto) As for the ihash issue, after giving this some thought I tend to keep it as it is, so you will have to use it on your Tru64 drives. At least for the next Cygwin release 1.7.7. If it's getting too awkward at some point, we can discuss this again. As you see, I have quite a lot of network drives, so I'm considering putting the ihash option globally to the uncommented /cygdrive mountpoint in /etc/fstab to cure all drives altogether. Will that cause any disadvantages for the real hardware NTFS drives C: and D:? (Doesn't look so at a first glance.) Please note the nice effect that ihashing /cygdrive/e also cures //dlanserv/KRAMSKI$, my Cygwin $HOME, which - apart from this testing - is not explicitly listed by mount. (My home share //dlanserv/KRAMSKI$ is mapped to E: on Windows). Regards, Heinz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server
While Cygwin 1.5 played well with our legacy file server (Tru64 Advanced Server V5.1B-4 ECO2), 1.7 does not. Although I seem to have sufficient write permissions (and actually can write to files), renaming (mv-ing) files fails with 1.7.1, 1.7.5-1 and 1.7.6-1 (others not tested) like this: $ pwd //dlanserv/KRAMSKI$/testperms $ touch somefile $ ls otherfile $ ls -la total 4113 drwxr-xr-x+ 2 kramski Domain Users 8192 2010-08-23 15:53 ./ drwx--+ 84 kramski Domain Users 8192 2010-08-23 15:35 ../ -rw-r--r-- 1 kramski Domain Users 19 2010-08-23 15:53 otherfile -rw-r--r-- 1 kramski Domain Users0 2010-08-23 15:53 somefile $ getfacl somefile # file: somefile # owner: kramski # group: Domain Users user::rw- group::r-- mask:rwx other:r-- $ rm otherfile $ mv somefile newfile mv: cannot move `somefile' to `newfile': Permission denied With 1.7.5, it was at least possible to copy files successfully. After upgrading to 1.7.6-1, cp now also fails strangely: $ cp somefile copyfile cp: skipping file `somefile', as it was replaced while being copied Mounting with the noacl option doesn't help: $ mount -o noacl //dlanserv/kramski$ /mnt mount: warning - /mnt does not exist. mount: defaulting to 'notexec' mount option for speed since native path references a remote share. Use '-f' option to override. $ mount //dlanserv/kramski$ on /mnt type cifs (text,notexec,noacl,user) $ cd /mnt/testperms $ ls -la total 3088 drwxr-xr-x 2 kramski Domain Users 8192 2010-08-23 15:53 ./ drwxr-xr-x 84 kramski Domain Users 8192 2010-08-23 15:35 ../ -rw-r--r-- 1 kramski Domain Users0 2010-08-23 15:53 somefile $ mv somefile newfile2 mv: cannot move `somefile' to `newfile2': Permission denied Here is some info about the network share: $ /usr/lib/csih/getVolInfo //dlanserv/KRAMSKI$/ Device Type: 7 Characteristics: 10 Volume Name: DLANSERV Serial Number : 4294967292 Max Filenamelength : 255 Filesystemname : NTFS Flags : 8 FILE_CASE_SENSITIVE_SEARCH : FALSE FILE_CASE_PRESERVED_NAMES : FALSE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: TRUE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE Using Windows explorer, every file operation is possible. Tru64 Advanced Server is a proprietary Unix port of NT4 and should more or less behave like an NT server. Any ideas how to make it work with Cygwin 1.7? TIA Heinz Cygwin Configuration Diagnostics Current System Time: Mon Aug 23 16:24:33 2010 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\WINDOWS\system32\WindowsPowerShell\v1.0 C:\Programme\dogro\profiskalp3\bin X:\cenvi\win32 c:\bin32 c:\cygwin\bin C:\Programme\oraic_112 C:\Programme\ora102\bin x:\bin32 Output from c:\cygwin\bin\id.exe UID: 11076(kramski) GID: 10513(Domain Users) 10513(Domain Users) 545(Benutzer) 547(Hauptbenutzer)12681(AK-ALS-ro) 12694(AK-Anfragen)12063(AK-Bestandserh) 12837(AK-Controlling) 12285(AK-DiDo) 12026(AK-Leaf)12826(AK-Literatur-im-Netz) 12027(AK-Malvine) 12518(AK-Musikalien) 12134(AK-relaunch)12141(AK-relaunch-1) 12486(AK-Schillerbibl)12122(AK-Schillerjahr2005) 12135(AK-StundemitderMaus)12638(Belegschaft) 12254(besterh)12670(difo) 11023(edv)11020(edvext) 12255(eentw) 11798(entwicklung) 11907(entwicklung_org)11245(fidelio) 11014(kessler)12440(m3_admin) 12438(m3_redakteur) 12630(PRJ-Edition-Gundolf) 12459(PRJ-Gernhardt-Brunnenhefte) 12843(PRJ-GPA-Umsetzung) 12884(PRJ-GPA-Ums_archiv) 12879(PRJ-GPA-Ums_archiv_k) 12885(PRJ-GPA-Ums_bibl) 12880(PRJ-GPA-Ums_bibl_k) 12887(PRJ-GPA-Ums_direkt) 12882(PRJ-GPA-Ums_direkt_k) 12886(PRJ-GPA-Ums_entw) 12888(PRJ-GPA-Ums_verw) 12883(PRJ-GPA-Ums_verw_k) 12669(PRJ-Juenger-digital) 12748(PRJ-Magazinbau-Plenum) 12668(PRJ-Schiller-digital) 11025(put)
Re: 1.7: Basic file operations fail on network shares provided by Tru64 Advanced Server
Am 24.08.2010 14:21, schrieb Corinna Vinschen: I prepared three test DLLs which all request another set of access rights: http://cygwin.de/cygwin-ug-177/cygwin1-test1.dll.bz2 (md5sum 29c3d46465113e69922938a65f693c61) http://cygwin.de/cygwin-ug-177/cygwin1-test2.dll.bz2 (md5sum 8e2facf7fc0641f130a2ed2b69c5665a) http://cygwin.de/cygwin-ug-177/cygwin1-test3.dll.bz2 (md5sum c3b52a03d47fc068b5915a95710723b3) Would you mind to test all three and report back? Good news: mv works with test2 (but fails with test1 and test3). Thanks a lot! RCS now works again (also in Windows Emacs), and so does a ~ 1300 lines script I'm currently working on. Is it safe to use this cygwin1-test2.dll for serious work? We are just preparing a new master image for several PCs and would like to include a working Cygwin 1.7. Thanks again, Heinz -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
md5sum /dev/fd0 fails with 1.5.25-15 (works with 1.5.24-2)
With cygwin1.dll 1.5.24-2 I am able to checksum the raw floppy device successfully using md5sum: $ md5sum /dev/fd0 f8e9627946048ac9bc3109478ef09215 */dev/fd0 After upgrading to 1.5.25-15 I now get this error: $ md5sum /dev/fd0 md5sum: /dev/fd0: No space left on device Any help is greatly appreciated. Regards, Heinz Cygwin Configuration Diagnostics Current System Time: Fri Aug 08 21:44:41 2008 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: f:\bin C:\cygwin\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin f:\bin C:\cygwin\bin C:\cygwin\usr\X11R6\bin f:\cenvi\WIN32 c:\Programme\Python25 c:\WINDOWS\system32\WindowsPowerShell\v1.0 c:\Programme\Gemeinsame Dateien\GTK\2.0\bin c:\WINDOWS\system32 c:\WINDOWS c:\WINDOWS\system32\WBEM C:\cygwin\bin Output from C:\cygwin\bin\id.exe (nontsec) UID: 1003(sysbuilder) GID: 1006(bofh) 513(Kein) 544(Administratoren) 545(Benutzer) 1006(bofh)1020(homebanking) 1014(photos) 1019(videos) Output from C:\cygwin\bin\id.exe (ntsec) UID: 1003(sysbuilder) GID: 1006(bofh) 513(Kein) 544(Administratoren) 545(Benutzer) 1006(bofh)1020(homebanking) 1014(photos) 1019(videos) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'sysbuilder' PWD = '/home/SysBuilder' CYGWIN = 'ntsec server' HOME = '/home/SysBuilder' MAKE_MODE = 'unix' HOMEPATH = '\Dokumente und Einstellungen\SysBuilder' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man:/usr/share/qt3/doc/man:/usr/X11R6/man' APPDATA = 'C:\Dokumente und Einstellungen\SysBuilder\Anwendungsdaten' HOSTNAME = 'cordl' DEVKITARM = '/c/Programme/devkitPro/devkitARM' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 15 Stepping 6, GenuineIntel' WINDIR = 'C:\WINDOWS' TEXDOCVIEW_txt = 'cygstart %s' TEXDOCVIEW_dvi = 'cygstart %s' QTDIR = '/usr/lib/qt3' OLDPWD = '/cygdrive/f/programme/puttycyg' CMMPATH = 'f:\cenvi\win32;f:\cenvi\winall;f:\cenvi\win;f:\cenvi\all;f:\cenvi\dos' USERDOMAIN = 'CORDL' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Dokumente und Einstellungen\All Users' DEVMGR_SHOW_NONPRESENT_DEVICES = '1' !:: = '::\' TEMP = '/cygdrive/c/DOKUME~1/SYSBUI~1/LOKALE~1/Temp' COMMONPROGRAMFILES = 'C:\Programme\Gemeinsame Dateien' DEVKITPRO = '/c/Programme/devkitPro' SOUND = 'OnBoard' QTJAVA = 'C:\Programme\QuickTime\QTSystem\QTJava.zip' USERNAME = 'SysBuilder' GS_PROG = 'C:\Programme\gs\gs8.54\bin\gswin32.exe' TEXDOCVIEW_pdf = 'cygstart %s' PROCESSOR_LEVEL = '6' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' TEXDOCVIEW_html = 'cygstart %s' USERPROFILE = 'C:\Dokumente und Einstellungen\SysBuilder' QMAKESPEC = '/usr/lib/qt3/mkspecs/cygwin-g++' PS1 = '\h:/home/SysBuilder\$' LOGONSERVER = '\\CORDL' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' HOMEDRIVE = 'C:' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/cygdrive/c/DOKUME~1/SYSBUI~1/LOKALE~1/Temp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = 'HP PSC 950' CVS_RSH = '/bin/ssh' PROCESSOR_REVISION = '0f06' CLASSPATH = '.;C:\Programme\QuickTime\QTSystem\QTJava.zip' PKG_CONFIG_PATH = '/usr/X11R6/lib/pkgconfig' TEXDOCVIEW_ps = 'cygstart %s' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Programme' DISPLAY = '127.0.0.1:0' NUMBER_OF_PROCESSORS = '2' SESSIONNAME = 'Console' COMPUTERNAME = 'CORDL' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Software\Cygnus Solutions HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2 HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2 (default) = '/cygdrive' cygdrive flags = 0x0022 HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/ (default) = 'C:\cygwin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/home (default) = 'e:\home' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin (default) = 'C:\cygwin/bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib (default) = 'C:\cygwin/lib' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/local/bin (default) = 'f:\bin' flags = 0x000a HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options a: fd FAT 0Mb 55% CPUN c: hd NTFS152601Mb 41% CP CS UN PA FC Windows d: hd NTFS 32765Mb 2% CP CS UN PA FC Reserve e: hd NTFS 87110Mb 99% CP CS UN PA FC Daten f: hd NTFS 32765Mb 45% CP CS UN PA FC Share g: hd NTFS305242Mb 86% CP CS UN PA FC Blobs h: fd N/AN/A i: fd N/AN/A
