spurious eof to M-x shell child stdin
in a program initiated from the shell initiated w/ M-x shell, an input
line of 512 characters results in a spurious EOF to the program. here
are three steps to reproduce the problem, and some additional actions to
compare the actual and expected behaviors:
(A) compile this C program:
cat drain-stdin.c EOF
#include stdio.h
int
main (int argc, char *argv)
{
int count = 0;
int result;
unsigned char byte;
while (0 (result = read (0, byte, 1)))
{
count++;
printf ([%d:%d] %c\n, result, count, byte);
}
printf (count: %d\n, count);
return 0;
}
EOF
gcc -o /tmp/drain-stdin drain-stdin.c
(B) create a long input line:
(let ((s (apply 'concat (make-list 32 0123456789ABCDEF)))
(require-final-newline nil))
(with-temp-buffer
(insert s)
(write-region (point-min) (point-max) /tmp/.512)))
(C) run the program under M-x shell, giving it the input:
M-x shell
/tmp/drain-stdin RET
(insert-file-contents /tmp/.512)
(end-of-line)
RET
(D) run the program noninteractively under M-x shell
/tmp/drain-stdin /tmp/.512
(E) likewise, under a regular terminal (outside emacs):
/tmp/drain-stdin /tmp/.512
(F) likewise, with M-x compile
/tmp/drain-stdin /tmp/.512
for (C) i see output that ends with:
[1:503] 6
[1:504] 7
[1:505] 8
[1:506] 9
[1:507] A
[1:508] B
count: 508
$ bash: CDEF: command not found
for (D), (E) and (F), i see output that ends with:
[1:507] A
[1:508] B
[1:509] C
[1:510] D
[1:511] E
[1:512] F
count: 512
i believe (D), (E) and (F) are correct. all behaviors were reproducible
w/ emacs from cvs and emacs 21.4, started with -q --no-site-file.
thi
In GNU Emacs 22.0.98.2 (i686-pc-linux-gnu)
of 2007-04-20 on ambire
Windowing system distributor `The XFree86 Project, Inc', version 11.0.4031
configured using `configure '--prefix' '/home/ttn/local'
'CPPFLAGS=-DSITELOAD_PURESIZE_EXTRA=2''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: C
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: C
locale-coding-system: nil
default-enable-multibyte-characters: t
Major mode: Man
Minor modes in effect:
shell-dirtrack-mode: t
display-time-mode: t
mouse-wheel-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
unify-8859-on-encoding-mode: t
utf-translate-cjk-mode: t
auto-compression-mode: t
transient-mark-mode: t
Recent input:
C-a C-a C-a C-a C-a C-x C-s M-m M-p RET C-x C-k C-x
s M-p M-p return C-x i M-p return C-e return
C-x C-f M-p RET C-x h M-w C-x C-f C-a C-f C-f C-k .
e backspace b a s r h backspace backspace h r
tab return C-x C-f . v a r tab RET C-s E M A
C S C-s C-a C-a C-l M-: ( g e t e n v SPC E M A C
S ) return C-x s e c h o SPC $ P A G E R return
C-x b RET C-x C-b C-n C-n C-n RET C-x h M-w M-x r e
p o tab r tab return s p u r i o u s SPC e o
f SPC v i a SPC backspace backspace backspace
backspace t h r o u g h backspace backspace backspace
backspace backspace backspace backspace backspace
SPC t o SPC M - x SPC s h e l l SPC c h i l backspace
backspace backspace backspace c h i backspace
backspace backspace c h i d l r e n SPC backspace
backspace backspace backspace backspace backspace
l d r e n SPC s t d i n return C-p C-p C-p C-p C-p
C-n C-e M-b M-b M-f backspace backspace backspace
M- M- C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-p C-p C-p C-p C-p C-p C-p C-n C-x 1 C-p C-p C-p
C-p C-p C-p C-n C-n C-n C-n C-n C-n C-h c C-c C-a C-x
C-k C-x C-g M-x m a n return r e backspace backspace
2 SPC r e a d return C-x 0 C-x b RET C-x b RET C-x
b C-g M-x M-p M-p return
Recent messages:
Loading emacsbug...done
Fill column set to 72 (was 78)
Loading mailalias...done
Mark set [2 times]
C-c C-a is undefined
Loading man...done
Invoking man 2 read in the background
Please wait: formatting the 2 read man page...
2 read man page formatted
Loading tabify...done
Quit
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Fwd: Re: beginning-of-defun]
From: Andreas Roehler [EMAIL PROTECTED] Date: Mon, 17 Jul 2006 08:06:26 +0200 Correct my answer in this point. Here a hopefully better one: What was sent indeed was a `beginning-of-defun' in his true understanding (as I conceive that) - nothing more. After that we could have a function dealing with a group of function-forms in Emacs Lisp while extending the reg-rexp appropriate, i.e. a `beginning-of-function'. in vietnamese, there is one word for both blue and green, and one needs to specialize w/ other words when talking about the color of the sea or the color of the tree leaves. changing the discourse requires introducing specific terms, convincing people that their usage of the old terms is out of date, and providing a way for people to slowly change their speech. here it is a similar situation: other people's concept of the term defun is much larger than your concept of true defun. you have introduced specific terms and have made arguments that may or may not convince people (that is up to people to decide for themselves), but you have not yet provided a way for people to slowly change their usage. to get people to change you have to throw your idea ahead, and walk WITH them towards it, even if that is more work. in the context of these emacs lisp functions, this means that your proposal is unevaluatable (or at best, only partially evaluatable, with inconclusive results) until all the After that... stuff (i.e., code) is included. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Fwd: Re: beginning-of-defun]
From: Andreas Roehler [EMAIL PROTECTED] Date: Mon, 10 Jul 2006 15:46:02 +0200 It's not just for fun I entered this matter. `beginning-of-defun' is buggy - and a lot of forms which rely on it. given the discussion so far i remain unconvinced there is a bug. note however: i'm not stopping you from continuing, personally. if you post code as the way to propose the bug fix, it that will be easier to evaluate its merits. remember to not break callers (both included w/ emacs and external) of `beginning-of-defun'. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: beginning-of-defun
Andreas Roehler [EMAIL PROTECTED] writes: Wrong, as at the start of the enclosing form. well, defun here actually means top-level form; the command works w/ all kinds of sexps, whether or not they are actually `defun's. the way to make the behavior arbitrarily more precise is to customize `beginning-of-defun-function'. for example, see `python-beginning-of-defun' in progmodes/python.el. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: [Fwd: Re: beginning-of-defun]
Andreas Roehler [EMAIL PROTECTED] writes: `defun' is a special form with a special meaning in emacs-lisp yes, but defun is also in common parlance a top-level form. these two meanings are congruent but not identical. you have to sort of alternatively squint and relax your ears to hear the similarity... Think it's disturbing to introduce a different meaning employing the same name. you get used to being disturbed w/ a little practice. Certainly a function `beginning-of-top-level-form' is useful. However, it should be callable separate from `beginning-of-defun' and vice versa. here is a (self-testable in the right context ;-) toy: (global-set-key \C-\M-a (defun beginning-of-defun-just-defun-really-i-mean-it! () (interactive) (let ((beginning-of-defun-function (lambda () (search-backward (defun (point-min) t (beginning-of-defun `beginning-of-defun' should work right out of the box at least in Emacs Lisp. That's easily to be done - if the need is recognised so far. it works for my understanding of defun. more importantly, my understanding of defun is shared by many people, most of whom are probably uninclined to add something like the above function to emacs. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Documentation
[EMAIL PROTECTED] (Johan Bockgård) writes: * eval-current-buffer has been obsoleted and replaced by eval-buffer. Some places in the Emacs and Emacs Lisp manuals refer to both eval-current-buffer and eval-buffer, some refer only to eval-current-buffer. i've fixed those sites to use eval-buffer where it is mentioned solely. i left alone those where both eval-buffer and eval-current-buffer are mentioned. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Documentation
From: Richard Stallman [EMAIL PROTECTED]
Date: Wed, 05 Jul 2006 13:03:52 -0400
Thanks. Would you like to change the manual(s), too?
i have made changes in man/{building,faq}.texi and
lispref/{edebug,loading}.texi similarly. these were
chosen based on M-x find-grep eval-current-buffer.
thi
___
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: doc string for `yank' should mention paste
Eli Zaretskii [EMAIL PROTECTED] writes: From: Drew Adams [EMAIL PROTECTED] You're right, Eli. Once created, however, it normally exists forever, no? Yes, AFAIK. well, at least until the next (set-mark nil). thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Build problem: data.c error: argument noerror doesn't match prototype
Andrew M. Scott [EMAIL PROTECTED] writes: /stor/garray/src/savannah/emacs/src/data.c: In function `Findirect_function': /stor/garray/src/savannah/emacs/src/data.c:1941: error: argument noerror doesn't match prototype /stor/garray/src/savannah/emacs/src/data.c:1930: error: prototype declaration gmake[2]: *** [data.o] Error 1 should be fixed in cvs now. thi ___ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: Problems with longlines-mode
From: Chong Yidong [EMAIL PROTECTED] Date: Mon, 22 Aug 2005 17:15:35 -0400 (EDT) Could someone with CVS write access check this in? please write a ChangeLog entry so that i don't need to run the risk of writing one incorrectly. then i will be happy to check this in. btw, maybe it is better to use `inhibit-read-only'? it allows more precise control. thi ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
Re: comments in .mailrc treated inconsistently
Roland Winkler [EMAIL PROTECTED] writes: As I said, I do not know whether programs like /bin/mail understand such comments. But I find these comments very helpful to organize the entries in my .mailrc. The reason I want to put the comments in the same line like an alias is that then I can much easier shuffle the lines in my .mailrc. i just now scanned /bin/mail source (2004-05 or thereabouts) and discovered that #... as a comment is only valid at the beginning of a line. of course, if you don't use /bin/mail, no worries... also, fwiw, i saw a sample ~/.mailrc (from sipb, no less!) that had commas between each alias -- this is incorrect. here is a comparison: /etc/aliases interested: you, me, an-ugly-dog ~/.mailrc alias interested you me an-ugly-dog thi ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
local var evaluation order
Dan Nicolaescu [EMAIL PROTECTED] writes: -*- mode: grep; default-directory: ~/src/emacs/lisp/ -*- it seems that it's just not used in the right order. maybe this is related to another bug: w/ recent (this week) emacs from cvs, this small file: --8 - level 1 - level 2 ## Local Variables: ## mode: outline ## outline-regexp: \\([ ][ ]\\)*- ## End: ---8- does not fontify, whereas w/ older emacs versions it does. it also does not fontify after reversing the order of the `mode:' and `outline-regexp:' lines. if i set-default the value of `outline-regexp', however, it fontifies. (emacs -q --no-site-file and global font lock mode enabled.) thi ___ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
