Re: my problems with dired

J.H.Petersen (J.Petersen@qmw.ac.uk)
Mon, 28 Feb 1994 13:45:08 GMT 

Hi Sandy,

Thanks for the replies:

> 
> Jens,
> 
> On Tue, 22 FEB 94 you wrote:
> 
>  > I just dumped core again!
>  > Again renaming the same file. It seems to do so consistently.
>  >  
>  > The exact error message was:
>  >  
>  > 	Fatal error (6).Abort (core dumped)
>  >  

> Not really.  This is certainly an emacs bug, with this error.
> What version of emacs are you running and on what?  It should
> be impossible to trigger a fatal error in emacs with lisp.
> Since no one else has hit this, I'm guessing that the bug may
> be peculiar to the particuliar emacs version & system type that
> you are using.

At the time of the message the host was running Emacs 19.19, but
this has now been upgraded to 19.22. I haven't had time to test
stability under 19.22 carefully yet, but it may not be crashing
so much now: at least it hasn't crashed yet ;-)

The host is a big(?) ICL DRS-6000 Unix mainframe, I think. I have
since been in contact with the system manager -- got them to
upgrade to 19.22 -- and he mentioning in passing that Emacs
doesn't usually compile without some tweaking on this machine. It
seems that the Unix on these machine is somewhat non-standard:-(
(see below too). So I am considering now if I should move to
another machine, which support Emacs fully.

> What you should do is try to determine a particular sequence of
> commands that triggers the core dump reliably, _starting from a
> fresh emacs_.  This is important, because efs caches heavily,
> so behaviour is only entirely predictable when you start from
> fresh.  If you can do this, then we should get in contact with
> either RMS or JWZ, depending on your emacs.  I can help here by
> maybe turning your sequence of efs commands into a specific a
> minimal set of lisp functions that cause the crash.  That'll
> make it much easier for them to find the bug.

> --sandy


> >>>>> On Tue, 22 Feb 1994 12:40:18 GMT,
>       J.Petersen@qmw.ac.uk (J.H.Petersen) said:
> 
>  > I hope it's ok to ask about `dired' here?
> 
> Yep.
> 
>  > Why is it that when I try to `tar xvf' a file in dired (with
>  > `!') I get:
> 
>  > 	tar: cannot open texfiles.tar.
> 
> It means exactly what it says.  The tar file cannot open texfiles.tar.
> That error is from the tar program, not dired.  Does the file exist?
> Is it in the directory in which you are executing the shell command?

Yes, it exists alright. That why it's strange! It worked ok under
the FSF dired on my machine.

> In dired shell commands execute in the subdirectory containing the
> point.  It always says in the prompt for the shell command what the
> execution directory will be.
> 
>  > Also the recursive deleting doesn't seem to work too well for
>  > me. When I try to delete a non-empty directory I get:
> 
>  > (error Failed to recusively delete /nfs/alpha/mnt_c7d2s4/ugap114/tex/tmp)
> 
>  > 1 of 1 deletion failed:
>  > 	Tue Feb 22 12:33:31 1994	Buffer `tex'
> 
>  > Similarly if a do `! rm -r RET' on the directory tmp/, the
>  > deletion fails to work (it used to under the dired that
>  > comes FSF 19).
> 
> This looks to me like like rm is broken, or does not take the R
> switch.  ! does no fancy handling of commands; it just sends them to
> the shell.  Can you rm -R from the shell on your system?
> 
> --sandy
> 

Indeed, the ICL DRS/NX rm doesn't accept -R (only -r).

It's a shame really, since I have all my mail coming in on this
computer.... so I don't really want to move it over to
workstation unless I have to. Maybe I'll just have to stop using
tree-dired on it :-(.

-Jens