* bug#58192: AW: bug#58192: 28.2; RCS integration issue [not found] ` <<83edvtdp95.fsf@gnu.org> @ 2022-09-30 12:45 ` Meyer, Thomas 2022-09-30 12:57 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Meyer, Thomas @ 2022-09-30 12:45 UTC (permalink / raw) To: Eli Zaretskii, Meyer, Thomas; +Cc: 58192 Eli, thanks, using the rcs port from https://sourceforge.net/projects/ezwinports/, I cannot reproduce the issue! The issue must then lie within Cygwin, or within the coupling of both through the wrapper script, this will require some deeper digging at our side I guess. Do you believe that it will be sufficient to work with RCS version 5.7.1 from 2006? Cygwin says rcs --version rcs (GNU RCS) 5.10.1 Copyright (C) 2010-2022 Thien-Thi Nguyen Copyright (C) 1990-1995 Paul Eggert Copyright (C) 1982,1988,1989 Walter F. Tichy, Purdue CS ... My hope was that recent versions of RCS might be capable of handling the UCS-2 LE BOM (UTF-16) format used by windows registry files, but I did not check yet. Thanks again, Thomas > -----Ursprüngliche Nachricht----- > Von: Eli Zaretskii <eliz@gnu.org> > Gesendet: Freitag, 30. September 2022 14:24 > An: Meyer, Thomas <Thomas.Meyer@dla-marbach.de> > Cc: 58192@debbugs.gnu.org > Betreff: Re: bug#58192: 28.2; RCS integration issue > > [Please use Reply All to keep the bug tracker on the CC list.] > > > Date: Fri, 30 Sep 2022 13:56:06 +0200 (CEST) > > From: "Meyer, Thomas" <Thomas.Meyer@dla-marbach.de> > > > > Eli, > > > > yes, I missed some information, the word "bla" was typed in as > > comment/summary for the commit. > > > > Here the full details of my actions: > > > > To reproduce: > > > > find new file in new directory > > C-x v v (vc-next-action) > > Registration will work fine (Registering > > (c:/Users/meyert/Documents/RCS-test/a.txt)... done) change file > > (inserted a new line) save file C-x v v (vc-next-action) -> first > > error: a checkout is done, erasing the changes > > This is not an error: with RCS you must check-out the file before you can > modify it, because RCS is a locking VCS. Don't you see the buffer > displayed as read-only (with "%%" in the mode line) before you check-out > the file? > > > change file again (inserted a new line) save file C-x v v > > (vc-next-action) Buffer *vc-log* prompts for a summary Enter "Bla" as > > summary C-c C-c (log-edit-done) check-in fails: > > > > Buffer *vc* displays the following content: > > > > c:\Users\meyert\Documents\RCS-test>c:\cygwin64\bin\rcs.exe ci -j -u1 > > "-mSummary: Bla > > ci: no input file > > ci aborted > > > > Buffer *Messages* reports > > > > Checking in c:/Users/meyert/Documents/RCS-test/a.txt... > > progn: Failed (status 1): ci -j -u1 -mSummary: Bla RCS/a.txt,v > > > > interstingly, the buried buffer *vc-log* display a line break after the > "Bla", that I never entered! > > That is the problem: you need to find out how that happened. Windows > shell doesn't support newlines embedded in command lines. > > It doesn't happen in my case, FWIW. > > > d=`echo "$0" | sed 's|[^/]*$||'` > > exec "$d"rcs ci "$@" > > > > # ci ends here > > > > These wrappers are available only in the Cygwin shell, so we need > > Windows wrappers, e.g. > > > > ci.cmd > > > > c:\cygwin64\bin\bash -c '/bin/%~n0 %*' > > It's possible that the newline gets added as result of these multiple > indirections. Or maybe something else is at work here: with my setup, > which uses just ci.exe, I cannot reproduce the problem. Perhaps stepping > with Edebug through vc-rcs-checking would reveal something? > Do you see the variable 'comment' there having the newline? > > > If you know better ways of coupling Emacs on Windows with Cygwin, > > please let me know. > > > > Other free ports of RCS on windows are older than dirt, I fear. > > Well, I'm a happy long-time user of RCS 5.7.1 ;-) > > > I might add that the same emacs install has no problems when > > performing git integration. > > > > Kind regards, Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58192: 28.2; RCS integration issue 2022-09-30 12:45 ` bug#58192: AW: bug#58192: 28.2; RCS integration issue Meyer, Thomas @ 2022-09-30 12:57 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2022-09-30 12:57 UTC (permalink / raw) To: Meyer, Thomas; +Cc: 58192 > Date: Fri, 30 Sep 2022 14:45:34 +0200 (CEST) > From: "Meyer, Thomas" <Thomas.Meyer@dla-marbach.de> > Cc: 58192@debbugs.gnu.org > > thanks, using the rcs port from https://sourceforge.net/projects/ezwinports/, > I cannot reproduce the issue! OK, so I guess it isn't Emacs's fault after all. > The issue must then lie within Cygwin, or within the coupling of both > through the wrapper script, this will require some deeper digging at > our side I guess. Yes, I agree. > Do you believe that it will be sufficient to work with RCS version > 5.7.1 from 2006? It is good enough for my purposes, but I cannot tell more than that. That port does include quite a few of Windows-specific changes, to make it work reliably on Windows. > Cygwin says > > rcs --version > rcs (GNU RCS) 5.10.1 > Copyright (C) 2010-2022 Thien-Thi Nguyen > Copyright (C) 1990-1995 Paul Eggert > Copyright (C) 1982,1988,1989 Walter F. Tichy, Purdue CS > ... > > My hope was that recent versions of RCS might be capable of handling > the UCS-2 LE BOM (UTF-16) format used by windows registry files, but I > did not check yet. That would need RCS to support 'wchar_t *' strings, which I'd be surprised if it did. The "usual" way of Unix programs to deal with non-ASCII text is to assume it's in UTF-8, not UTF-16, which allows to keep using 'char *' strings. Cygwin uses UTF-8 as its main encoding, so my bet is that the Cygwin port of RCS relies on UTF-8 encoding. But those are just guesses; I never had time to study all the recent changes to RCS. ^ permalink raw reply [flat|nested] 6+ messages in thread
[parent not found: <<4ef14f4b-860f-41df-a785-4c3cca1d5e67@dla-marbach.de>]
[parent not found: <<83mtahdtuz.fsf@gnu.org>]
[parent not found: <36ba9fa6-e6fd-4d39-8279-785c7ae270b2@dla-marbach.de>]
* bug#58192: 28.2; RCS integration issue [not found] ` <36ba9fa6-e6fd-4d39-8279-785c7ae270b2@dla-marbach.de> @ 2022-09-30 12:24 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2022-09-30 12:24 UTC (permalink / raw) To: Meyer, Thomas; +Cc: 58192 [Please use Reply All to keep the bug tracker on the CC list.] > Date: Fri, 30 Sep 2022 13:56:06 +0200 (CEST) > From: "Meyer, Thomas" <Thomas.Meyer@dla-marbach.de> > > Eli, > > yes, I missed some information, the word "bla" was typed in as > comment/summary for the commit. > > Here the full details of my actions: > > To reproduce: > > find new file in new directory > C-x v v (vc-next-action) > Registration will work fine (Registering > (c:/Users/meyert/Documents/RCS-test/a.txt)... done) > change file (inserted a new line) > save file > C-x v v (vc-next-action) -> first error: a checkout is done, erasing the changes This is not an error: with RCS you must check-out the file before you can modify it, because RCS is a locking VCS. Don't you see the buffer displayed as read-only (with "%%" in the mode line) before you check-out the file? > change file again (inserted a new line) > save file > C-x v v (vc-next-action) > Buffer *vc-log* prompts for a summary > Enter "Bla" as summary > C-c C-c (log-edit-done) > check-in fails: > > Buffer *vc* displays the following content: > > c:\Users\meyert\Documents\RCS-test>c:\cygwin64\bin\rcs.exe ci -j -u1 "-mSummary: Bla > ci: no input file > ci aborted > > Buffer *Messages* reports > > Checking in c:/Users/meyert/Documents/RCS-test/a.txt... > progn: Failed (status 1): ci -j -u1 -mSummary: Bla > RCS/a.txt,v > > interstingly, the buried buffer *vc-log* display a line break after the "Bla", that I never entered! That is the problem: you need to find out how that happened. Windows shell doesn't support newlines embedded in command lines. It doesn't happen in my case, FWIW. > d=`echo "$0" | sed 's|[^/]*$||'` > exec "$d"rcs ci "$@" > > # ci ends here > > These wrappers are available only in the Cygwin shell, so we need > Windows wrappers, e.g. > > ci.cmd > > c:\cygwin64\bin\bash -c '/bin/%~n0 %*' It's possible that the newline gets added as result of these multiple indirections. Or maybe something else is at work here: with my setup, which uses just ci.exe, I cannot reproduce the problem. Perhaps stepping with Edebug through vc-rcs-checking would reveal something? Do you see the variable 'comment' there having the newline? > If you know better ways of coupling Emacs on Windows with Cygwin, > please let me know. > > Other free ports of RCS on windows are older than dirt, I fear. Well, I'm a happy long-time user of RCS 5.7.1 ;-) > I might add that the same emacs install has no problems when > performing git integration. > > Kind regards, Thomas ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58192: 28.2; RCS integration issue @ 2022-09-30 8:01 Meyer, Thomas 2022-09-30 10:44 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Meyer, Thomas @ 2022-09-30 8:01 UTC (permalink / raw) To: 58192 Dear emacs developers, we have an issue with vc-rcs, that we have been using for a long time, and which seems to be broken in 28.2 (actually first noticed this in 28.1): we are working on the Windows port available on http://ftp.gnu.org/gnu/emacs/windows/emacs-28/. By tracing the activity of e.g. ci command with process monitor, we found that the commands fail because an erraneous line break is send with the command, e.g. ---- PID: 7224, Command line: C:\Windows\system32\cmd.exe /c c:\bin\ci.cmd -j -u1 "-mSummary: bla " RCS/x.txt,v ---- To reproduce: find new file in new directory C-x v v (vc-next-action) Registration will work fine (Registering (c:/Users/meyert/Documents/RCS-test/a.txt)... done) change file C-x v v (vc-next-action) -> first error: a checkout is done, erasing the changes change file again C-x v v (vc-next-action) -> second error: check-in fails: Press C-c C-c when you are done editing. Enter a change comment. Type C-c C-c when done Checking in c:/Users/meyert/Documents/RCS-test/a.txt... progn: Failed (status 1): ci -j -u1 -mSummary: bla RCS/a.txt,v Do you require further details? We use Cygwin 3.3.5-1 for providing RCS under windows, but I guess that this is not where the issue arises. Kind regards, Thomas generated info: -------------------------------------------------------------------------------- In GNU Emacs 28.2 (build 2, x86_64-w64-mingw32) of 2022-09-13 built on AVALON Windowing system distributor 'Microsoft Corp.', version 10.0.19044 System Description: Microsoft Windows 10 Education (v10.0.2009.19044.2006) Configured using: 'configure --with-modules --without-dbus --with-native-compilation --without-compress-install CFLAGS=-O2' Configured features: ACL GIF GMP GNUTLS HARFBUZZ JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP NOTIFY W32NOTIFY PDUMPER PNG RSVG SOUND THREADS TIFF TOOLKIT_SCROLL_BARS XPM ZLIB (NATIVE_COMP present but libgccjit not available) Important settings: value of $LANG: DEU locale-coding-system: cp1252 Major mode: Fundamental Minor modes in effect: tooltip-mode: t global-eldoc-mode: t show-paren-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t line-number-mode: t indent-tabs-mode: t transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug sendmail log-edit message rmc puny rfc822 mml mml-sec epa epg rfc6068 epg-config gnus-util rmail rmail-loaddefs auth-source eieio eieio-core eieio-loaddefs password-cache json map text-property-search mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader ring pcvs-util add-log vc-filewise vc-mtn vc-hg rx vc-git diff-mode easy-mmode vc-bzr vc-dir edmacro kmacro ewoc vc-src vc-sccs vc-svn vc-cvs vc-rcs cl-seq pcase vc vc-dispatcher ediff ediff-merg ediff-mult cl-macs derived ediff-wind ediff-diff ediff-help ediff-init ediff-util time-date subr-x misearch multi-isearch seq byte-opt gv bytecomp byte-compile cconv dired-aux cl-loaddefs cl-lib dired dired-loaddefs iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite emoji-zwj charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button loaddefs faces cus-face macroexp files window text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads w32notify w32 lcms2 multi-tty make-network-process native-compile emacs) Memory information: ((conses 16 217438 15563) (symbols 48 11284 1) (strings 32 32118 2137) (string-bytes 1 1074223) (vectors 16 15876) (vector-slots 8 274294 17668) (floats 8 55 290) (intervals 56 6409 275) (buffers 992 31)) ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58192: 28.2; RCS integration issue 2022-09-30 8:01 Meyer, Thomas @ 2022-09-30 10:44 ` Eli Zaretskii 2022-09-30 12:09 ` Eli Zaretskii 0 siblings, 1 reply; 6+ messages in thread From: Eli Zaretskii @ 2022-09-30 10:44 UTC (permalink / raw) To: Meyer, Thomas; +Cc: 58192 > Date: Fri, 30 Sep 2022 10:01:51 +0200 (CEST) > From: "Meyer, Thomas" <Thomas.Meyer@dla-marbach.de> > > Dear emacs developers, we have an issue with vc-rcs, that we have been > using for a long time, and which seems to be broken in 28.2 (actually > first noticed this in 28.1): we are working on the Windows port > available on http://ftp.gnu.org/gnu/emacs/windows/emacs-28/. > > By tracing the activity of e.g. ci command with process monitor, we > found that the commands fail because an erraneous line break is send > with the command, e.g. > > ---- > PID: 7224, Command line: C:\Windows\system32\cmd.exe /c c:\bin\ci.cmd -j -u1 "-mSummary: bla > " RCS/x.txt,v > ---- > > To reproduce: > > find new file in new directory > C-x v v (vc-next-action) > Registration will work fine (Registering (c:/Users/meyert/Documents/RCS-test/a.txt)... done) > change file > C-x v v (vc-next-action) -> first error: a checkout is done, erasing the changes > change file again > C-x v v (vc-next-action) -> second error: check-in fails: > > Press C-c C-c when you are done editing. > Enter a change comment. Type C-c C-c when done > Checking in c:/Users/meyert/Documents/RCS-test/a.txt... > progn: Failed (status 1): ci -j -u1 -mSummary: bla > RCS/a.txt,v > > Do you require further details? Where did the "bla" part come from? Emacs didn't generate it, did it? It's something you typed at some point, I guess? More generally, would you please describe the steps in full detail, including what you typed, exactly? Also, what does ci.cmd say? I'm not aware of any scripts in the RCS distribution; 'ci' should be a program, i.e. ci.exe. It could be that what ci.cmd does has some relevance for this issue. Thanks. ^ permalink raw reply [flat|nested] 6+ messages in thread
* bug#58192: 28.2; RCS integration issue 2022-09-30 10:44 ` Eli Zaretskii @ 2022-09-30 12:09 ` Eli Zaretskii 0 siblings, 0 replies; 6+ messages in thread From: Eli Zaretskii @ 2022-09-30 12:09 UTC (permalink / raw) To: Thomas.Meyer; +Cc: 58192 > Cc: 58192@debbugs.gnu.org > Date: Fri, 30 Sep 2022 13:44:36 +0300 > From: Eli Zaretskii <eliz@gnu.org> > > > Date: Fri, 30 Sep 2022 10:01:51 +0200 (CEST) > > From: "Meyer, Thomas" <Thomas.Meyer@dla-marbach.de> > > > > Dear emacs developers, we have an issue with vc-rcs, that we have been > > using for a long time, and which seems to be broken in 28.2 (actually > > first noticed this in 28.1): we are working on the Windows port > > available on http://ftp.gnu.org/gnu/emacs/windows/emacs-28/. > > > > By tracing the activity of e.g. ci command with process monitor, we > > found that the commands fail because an erraneous line break is send > > with the command, e.g. > > > > ---- > > PID: 7224, Command line: C:\Windows\system32\cmd.exe /c c:\bin\ci.cmd -j -u1 "-mSummary: bla > > " RCS/x.txt,v > > ---- > > > > To reproduce: > > > > find new file in new directory > > C-x v v (vc-next-action) > > Registration will work fine (Registering (c:/Users/meyert/Documents/RCS-test/a.txt)... done) > > change file > > C-x v v (vc-next-action) -> first error: a checkout is done, erasing the changes > > change file again > > C-x v v (vc-next-action) -> second error: check-in fails: > > > > Press C-c C-c when you are done editing. > > Enter a change comment. Type C-c C-c when done > > Checking in c:/Users/meyert/Documents/RCS-test/a.txt... > > progn: Failed (status 1): ci -j -u1 -mSummary: bla > > RCS/a.txt,v > > > > Do you require further details? > > Where did the "bla" part come from? Emacs didn't generate it, did it? > It's something you typed at some point, I guess? > > More generally, would you please describe the steps in full detail, > including what you typed, exactly? > > Also, what does ci.cmd say? I'm not aware of any scripts in the RCS > distribution; 'ci' should be a program, i.e. ci.exe. It could be that > what ci.cmd does has some relevance for this issue. FWIW, I've now tried to reproduce the problem, and was unable to. Here's what I did: emacs -Q C-x C-f hello.text <Type some text> C-x C-s C-x v v <This asks for a backend: answer "RCS RET"> <It then asks in which directory to create the repository: type RET> <Registration OK: "Registering (d:/usr/tmp/hello.txt)... done"> <The file is now displayed as read-only, as expected.> C-x v v <This checks out the file, so it could be modified: this is a must with RCS, and not a bug> <Modify the file> C-x C-s C-x v v <This shows a commit log buffer: Press C-c C-c when you are done editing. Enter a change comment. Type C-c C-c when done <Enter text in Summary and type C-c> <Check-in OK: "Checking in d:/usr/tmp/hello.txt...done"> <C-x v l then shows the expected log> So once again, more details are needed to investigate what's wrong in your case. An important detail: I used RCS I ported myself, which is available here: https://sourceforge.net/projects/ezwinports/files/ It's possible that using a Cygwin port of RCS somehow interferes with the native Emacs. Another possibly important factoid is that the file hello.txt I used in the above had DOS CRLF EOL format, as that is what the Windows port of RCS expects and produces when checking-out files. Bottom line: I cannot reproduce the problem on my system. ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2022-09-30 12:57 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <<<4ef14f4b-860f-41df-a785-4c3cca1d5e67@dla-marbach.de> [not found] ` <<<83mtahdtuz.fsf@gnu.org> [not found] ` <<36ba9fa6-e6fd-4d39-8279-785c7ae270b2@dla-marbach.de> [not found] ` <<83edvtdp95.fsf@gnu.org> 2022-09-30 12:45 ` bug#58192: AW: bug#58192: 28.2; RCS integration issue Meyer, Thomas 2022-09-30 12:57 ` Eli Zaretskii [not found] <<4ef14f4b-860f-41df-a785-4c3cca1d5e67@dla-marbach.de> [not found] ` <<83mtahdtuz.fsf@gnu.org> [not found] ` <36ba9fa6-e6fd-4d39-8279-785c7ae270b2@dla-marbach.de> 2022-09-30 12:24 ` Eli Zaretskii 2022-09-30 8:01 Meyer, Thomas 2022-09-30 10:44 ` Eli Zaretskii 2022-09-30 12:09 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git 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).