* bug#18851: 24.4; emacs cannot be started if the current directory has been removed @ 2014-10-27 13:33 Vincent Lefevre 2014-10-28 21:34 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: Vincent Lefevre @ 2014-10-27 13:33 UTC (permalink / raw) To: 18851 Emacs cannot be started if the current directory has been removed: $ mkdir foo && cd foo && rmdir ../foo && emacs -Q emacs: `get_current_dir_name' failed: No such file or directory zsh: exit 1 My old bug report in the Debian BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687171 In GNU Emacs 24.4.1 (x86_64-pc-linux-gnu, GTK+ Version 3.14.3) of 2014-10-25 on trouble, modified by Debian Windowing system distributor `The X.Org Foundation', version 11.0.11601000 System Description: Debian GNU/Linux unstable (sid) Configured using: `configure --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp --build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib --infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.4/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.4/site-lisp:/usr/share/emacs/site-lisp --with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' CPPFLAGS=-D_FORTIFY_SOURCE=2 LDFLAGS=-Wl,-z,relro' Important settings: value of $LC_COLLATE: POSIX value of $LC_CTYPE: en_US.UTF-8 value of $LC_TIME: en_DK value of $LANG: POSIX locale-coding-system: utf-8-unix Major mode: Lisp Interaction Minor modes in effect: display-time-mode: t show-paren-mode: t tooltip-mode: t mouse-wheel-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 column-number-mode: t line-number-mode: t transient-mark-mode: t Recent input: <escape> x r e p o r t - <tab> <return> Recent messages: Loading cjk-enc...done Loading /etc/emacs/site-start.d/50latex-cjk-common.el (source)...done Loading /etc/emacs/site-start.d/50latex-cjk-thai.el (source)...done Loading /etc/emacs/site-start.d/50psvn.el (source)...done Loading /etc/emacs/site-start.d/50python-docutils.el (source)...done Loading /etc/emacs/site-start.d/50rnc-mode.el (source)...done Loading /etc/emacs/site-start.d/50w3m-el.el (source)...done Loading /home/vinc17/share/emacs/site-lisp/mutteditor.el (source)...done Loading time...done For information about GNU Emacs and the GNU system, type C-h C-a. Load-path shadows: /usr/share/emacs24/site-lisp/css-mode/css-mode hides /usr/share/emacs/site-lisp/css-mode/css-mode /usr/share/emacs/24.4/site-lisp/debian-startup hides /usr/share/emacs/site-lisp/debian-startup /usr/share/emacs/site-lisp/autoconf/autotest-mode hides /usr/share/emacs/site-lisp/autotest-mode /usr/share/emacs24/site-lisp/cmake-data/cmake-mode hides /usr/share/emacs/site-lisp/cmake-mode /usr/share/emacs24/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/24.4/lisp/tempo /usr/share/emacs24/site-lisp/flim/hex-util hides /usr/share/emacs/24.4/lisp/hex-util /usr/share/emacs24/site-lisp/flim/md4 hides /usr/share/emacs/24.4/lisp/md4 /usr/share/emacs24/site-lisp/dictionaries-common/flyspell hides /usr/share/emacs/24.4/lisp/textmodes/flyspell /usr/share/emacs24/site-lisp/dictionaries-common/ispell hides /usr/share/emacs/24.4/lisp/textmodes/ispell /usr/share/emacs/site-lisp/rst hides /usr/share/emacs/24.4/lisp/textmodes/rst /usr/share/emacs24/site-lisp/css-mode/css-mode hides /usr/share/emacs/24.4/lisp/textmodes/css-mode /usr/share/emacs24/site-lisp/flim/hmac-md5 hides /usr/share/emacs/24.4/lisp/net/hmac-md5 /usr/share/emacs24/site-lisp/flim/sasl-ntlm hides /usr/share/emacs/24.4/lisp/net/sasl-ntlm /usr/share/emacs24/site-lisp/flim/sasl-cram hides /usr/share/emacs/24.4/lisp/net/sasl-cram /usr/share/emacs24/site-lisp/flim/ntlm hides /usr/share/emacs/24.4/lisp/net/ntlm /usr/share/emacs24/site-lisp/flim/sasl hides /usr/share/emacs/24.4/lisp/net/sasl /usr/share/emacs24/site-lisp/flim/hmac-def hides /usr/share/emacs/24.4/lisp/net/hmac-def /usr/share/emacs24/site-lisp/flim/sasl-digest hides /usr/share/emacs/24.4/lisp/net/sasl-digest /usr/share/emacs24/site-lisp/latex-cjk-thai/thai-word hides /usr/share/emacs/24.4/lisp/language/thai-word /usr/share/emacs24/site-lisp/html-helper-mode/html-helper-mode hides /usr/share/emacs/site-lisp/html-helper-mode/html-helper-mode /usr/share/emacs24/site-lisp/html-helper-mode/hhm-config hides /usr/share/emacs/site-lisp/html-helper-mode/hhm-config /usr/share/emacs24/site-lisp/html-helper-mode/tempo hides /usr/share/emacs/site-lisp/html-helper-mode/tempo /usr/share/emacs24/site-lisp/html-helper-mode/visual-basic-mode hides /usr/share/emacs/site-lisp/html-helper-mode/visual-basic-mode Features: (shadow sort gnus-util mail-extr warnings emacsbug message format-spec rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils time cus-start cus-load paren cc-styles cc-align cc-engine cc-vars cc-defs w3m-load jabber-autoloads time-date tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote make-network-process dbusbind gfilenotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs) Memory information: ((conses 16 91766 8297) (symbols 48 20147 0) (miscs 40 97 93) (strings 32 15277 5245) (string-bytes 1 446889) (vectors 16 9914) (vector-slots 8 393404 6798) (floats 8 69 91) (intervals 56 232 14) (buffers 960 12) (heap 1024 28626 975)) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-27 13:33 bug#18851: 24.4; emacs cannot be started if the current directory has been removed Vincent Lefevre @ 2014-10-28 21:34 ` Glenn Morris 2014-10-29 1:28 ` Vincent Lefevre ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Glenn Morris @ 2014-10-28 21:34 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 Vincent Lefevre wrote: > Emacs cannot be started if the current directory has been removed: It's easy to change that so that it switches to HOME instead (let's not worry about the case of HOME being missing too!); see patch at end. But then you run into the problem that `emacs -Q some-file' starts editing ~/some-file instead of /some/deleted/dir/some-file. So it probably still needs to throw an error and abort processing of any command-line option that involves a non-absolute file name (eg `emacs -l some-file' would also presumably do the wrong thing). So is it worth it? > My old bug report in the Debian BTS: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687171 IMO there's really no point reporting Emacs problems that aren't specific to Debian (and this issues obviously isn't) to the Debian bug tracker. They just sit there for some lengthy period of time, and only if they get forwarded here does something happen. (Although I do look at the Debian Emacs bug reports and had looked at that one.) *** src/buffer.c 2014-10-04 08:20:24 +0000 --- src/buffer.c 2014-10-04 18:59:30 +0000 *************** *** 5299,5305 **** pwd = get_current_dir_name (); if (!pwd) ! fatal ("`get_current_dir_name' failed: %s\n", strerror (errno)); /* Maybe this should really use some standard subroutine whose definition is filename syntax dependent. */ --- 5299,5315 ---- pwd = get_current_dir_name (); if (!pwd) ! { ! fprintf (stderr, "Warning: `get_current_dir_name' failed: %s\n\ ! Trying to change to home directory...\n", strerror (errno)); ! if (getenv ("HOME")) ! { ! chdir (getenv ("HOME")); ! pwd = get_current_dir_name (); ! } ! if (!pwd) ! fatal ("`get_current_dir_name' failed: %s\n", strerror (errno)); ! } /* Maybe this should really use some standard subroutine whose definition is filename syntax dependent. */ ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-28 21:34 ` Glenn Morris @ 2014-10-29 1:28 ` Vincent Lefevre 2014-10-29 3:50 ` Eli Zaretskii 2014-10-29 3:40 ` Eli Zaretskii 2014-10-29 10:57 ` Emacs bugs at the Debian BTS Ivan Shmakov 2 siblings, 1 reply; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 1:28 UTC (permalink / raw) To: Glenn Morris; +Cc: 18851 On 2014-10-28 17:34:59 -0400, Glenn Morris wrote: > Vincent Lefevre wrote: > > > Emacs cannot be started if the current directory has been removed: > > It's easy to change that so that it switches to HOME instead (let's not > worry about the case of HOME being missing too!); see patch at end. Is there any reason to switch to another directory? Why doesn't Emacs just ignore that the current directory has been removed (and report errors only when an access to it is really needed)? Note that the current directory can also be removed after Emacs is started, so I expect that Emacs already supports cases like that. In the init_buffer() function, it seems that pwd is used only for: bset_directory (current_buffer, make_unibyte_string (pwd, len)); If the current directory has been removed, couldn't Qnil be used (or, if not possible, ".")? Note: this is the first time (well, almost) I look at the Emacs C source. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 1:28 ` Vincent Lefevre @ 2014-10-29 3:50 ` Eli Zaretskii 2014-10-29 8:09 ` Vincent Lefevre 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 3:50 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 > Date: Wed, 29 Oct 2014 02:28:02 +0100 > From: Vincent Lefevre <vincent@vinc17.net> > Cc: 18851@debbugs.gnu.org > > On 2014-10-28 17:34:59 -0400, Glenn Morris wrote: > > Vincent Lefevre wrote: > > > > > Emacs cannot be started if the current directory has been removed: > > > > It's easy to change that so that it switches to HOME instead (let's not > > worry about the case of HOME being missing too!); see patch at end. > > Is there any reason to switch to another directory? Why doesn't > Emacs just ignore that the current directory has been removed > (and report errors only when an access to it is really needed)? Because Emacs needs to pretend to the user that it runs _in_ that directory, so that relative file names work as you'd expect. In this regard, Emacs is like the shell. > Note that the current directory can also be removed after Emacs > is started, so I expect that Emacs already supports cases like > that. No, it does not. Either the OS leaves the directory in existence until Emacs exits, or the OS prevents you from removing it. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 3:50 ` Eli Zaretskii @ 2014-10-29 8:09 ` Vincent Lefevre 2014-10-29 12:57 ` Stefan Monnier 2014-10-29 14:23 ` Eli Zaretskii 0 siblings, 2 replies; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 8:09 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18851 On 2014-10-29 05:50:12 +0200, Eli Zaretskii wrote: > > Date: Wed, 29 Oct 2014 02:28:02 +0100 > > From: Vincent Lefevre <vincent@vinc17.net> > > Cc: 18851@debbugs.gnu.org > > > > On 2014-10-28 17:34:59 -0400, Glenn Morris wrote: > > > Vincent Lefevre wrote: > > > > > > > Emacs cannot be started if the current directory has been removed: > > > > > > It's easy to change that so that it switches to HOME instead (let's not > > > worry about the case of HOME being missing too!); see patch at end. > > > > Is there any reason to switch to another directory? Why doesn't > > Emacs just ignore that the current directory has been removed > > (and report errors only when an access to it is really needed)? > > Because Emacs needs to pretend to the user that it runs _in_ that > directory, so that relative file names work as you'd expect. I don't expect anything about reative file names. But if I type "emacs foo", opening file "foo" from $HOME would be bad. > In this regard, Emacs is like the shell. The shell has no problems when the current directory has been removed. It can still run without needing to switch to $HOME. > > Note that the current directory can also be removed after Emacs > > is started, so I expect that Emacs already supports cases like > > that. > > No, it does not. Either the OS leaves the directory in existence > until Emacs exits, or the OS prevents you from removing it. Linux does neither. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 8:09 ` Vincent Lefevre @ 2014-10-29 12:57 ` Stefan Monnier 2014-10-29 14:27 ` Eli Zaretskii 2014-10-29 14:23 ` Eli Zaretskii 1 sibling, 1 reply; 31+ messages in thread From: Stefan Monnier @ 2014-10-29 12:57 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 > The shell has no problems when the current directory has been > removed. It can still run without needing to switch to $HOME. The problem is that the `emacs' process only access files using absolute file names (it basically doesn't use the process's current working directory, because every buffer has its own "current working directory"), so when the Emacs user thinks he's using a relative file name, Emacs really concatenates this relative file name to the value of `default-directory' and passes *that* to the OS. So the current Emacs C code really has no way to access a directory/file which is not accessible from the root directory. Stefan ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 12:57 ` Stefan Monnier @ 2014-10-29 14:27 ` Eli Zaretskii 2014-10-29 15:39 ` Vincent Lefevre 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 14:27 UTC (permalink / raw) To: Stefan Monnier; +Cc: vincent, 18851 > From: Stefan Monnier <monnier@iro.umontreal.ca> > Cc: Eli Zaretskii <eliz@gnu.org>, 18851@debbugs.gnu.org > Date: Wed, 29 Oct 2014 08:57:16 -0400 > > > The shell has no problems when the current directory has been > > removed. It can still run without needing to switch to $HOME. > > The problem is that the `emacs' process only access files using absolute > file names (it basically doesn't use the process's current working > directory, because every buffer has its own "current working > directory"), so when the Emacs user thinks he's using a relative file > name, Emacs really concatenates this relative file name to the value of > `default-directory' and passes *that* to the OS. > > So the current Emacs C code really has no way to access a directory/file > which is not accessible from the root directory. That's true, but my reading of the code is that the value of the directory where Emacs was started is used for the following: . the default-directory of *scratch* . invocation-name and invocation-directory, if Emacs was invoked via a relative file name, like "../foo/bar/emacs". In the first case, we could try using nil instead, maybe not all hell will break lose. The second case is rare even without the removal (and makes no sense to me). But I'd still like to hear the real-life use case behind this report. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 14:27 ` Eli Zaretskii @ 2014-10-29 15:39 ` Vincent Lefevre 2014-10-29 16:07 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 15:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18851 On 2014-10-29 16:27:13 +0200, Eli Zaretskii wrote: > > From: Stefan Monnier <monnier@iro.umontreal.ca> > > Cc: Eli Zaretskii <eliz@gnu.org>, 18851@debbugs.gnu.org > > Date: Wed, 29 Oct 2014 08:57:16 -0400 [...] > > So the current Emacs C code really has no way to access a directory/file > > which is not accessible from the root directory. The problem is precisely when Emacs is called on a absolute pathname. Currently Emacs quits instead of working on this file. I repeat that I'm NOT asking that Emacs should work with a pathname relative to a removed directory. > That's true, but my reading of the code is that the value of the > directory where Emacs was started is used for the following: > > . the default-directory of *scratch* IMHO, if the current directory no longer exists, the default-directory of *scratch* can be nil. > . invocation-name and invocation-directory, if Emacs was invoked via > a relative file name, like "../foo/bar/emacs". > > In the first case, we could try using nil instead, maybe not all hell > will break lose. The second case is rare even without the removal > (and makes no sense to me). emacs --eval '(setq default-directory nil) (find-file "~/out")' fails, but I wonder why. > But I'd still like to hear the real-life use case behind this report. Well, it happens that the current directory is removed for some reasons, either on purpose or because of some FS error (in particular if the FS is remote). Now, I may have already an application running with this current directory, for instance, a MUA. If I want to write a mail, the MUA will start an editor on an absolute pathname, Emacs in my case, with the same current directory. But Emacs cannot be started, just because the current directory no longer exists, meaning that I can't write my mail without restarting the whole application. Note: in some cases, one can still use a wrapper to change the current directory to an existing one, but this can be a bit dangerous in general, because if there are relative pathnames, one can end up with loading/writing an incorrect file instead of getting an error. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 15:39 ` Vincent Lefevre @ 2014-10-29 16:07 ` Eli Zaretskii 2014-10-29 16:44 ` Vincent Lefevre 2014-10-29 16:15 ` Andreas Schwab 2014-10-30 0:39 ` Stefan Monnier 2 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 16:07 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 > Date: Wed, 29 Oct 2014 16:39:59 +0100 > From: Vincent Lefevre <vincent@vinc17.net> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, 18851@debbugs.gnu.org > > > . the default-directory of *scratch* > > IMHO, if the current directory no longer exists, the default-directory > of *scratch* can be nil. > > > . invocation-name and invocation-directory, if Emacs was invoked via > > a relative file name, like "../foo/bar/emacs". > > > > In the first case, we could try using nil instead, maybe not all hell > > will break lose. The second case is rare even without the removal > > (and makes no sense to me). > > emacs --eval '(setq default-directory nil) (find-file "~/out")' > > fails, but I wonder why. You can assume without testing that there will be problems, because Emacs expects to find a meaningful default-directory in *scratch*. The only question is are those problems easy to solve, or are they extremely complex to solve. There's one more subtlety here which you might not be aware of: when Emacs comes up initially, its first steps through the startup process are made before it figures out the user locale and sets up the coding-systems required by that. Until that point, Emacs uses undecoded file names, i.e. essentially byte streams that it can barely interpret (unless they are pure-ASCII). So the code which gives you trouble, that is run very early during startup, is already complicated to support building and starting Emacs in a non-ASCII directory. > Well, it happens that the current directory is removed for some > reasons, either on purpose or because of some FS error (in particular > if the FS is remote). Now, I may have already an application running > with this current directory, for instance, a MUA. If I want to write > a mail, the MUA will start an editor on an absolute pathname, Emacs > in my case, with the same current directory. But Emacs cannot be > started, just because the current directory no longer exists, meaning > that I can't write my mail without restarting the whole application. Can't you use the --chdir command-line argument to make Emacs start in a safe place? Or does that not work in this situation? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 16:07 ` Eli Zaretskii @ 2014-10-29 16:44 ` Vincent Lefevre 0 siblings, 0 replies; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 16:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18851 On 2014-10-29 18:07:33 +0200, Eli Zaretskii wrote: > You can assume without testing that there will be problems, because > Emacs expects to find a meaningful default-directory in *scratch*. What will it do with this default-directory? > > Well, it happens that the current directory is removed for some > > reasons, either on purpose or because of some FS error (in particular > > if the FS is remote). Now, I may have already an application running > > with this current directory, for instance, a MUA. If I want to write > > a mail, the MUA will start an editor on an absolute pathname, Emacs > > in my case, with the same current directory. But Emacs cannot be > > started, just because the current directory no longer exists, meaning > > that I can't write my mail without restarting the whole application. > > Can't you use the --chdir command-line argument to make Emacs start in > a safe place? Or does that not work in this situation? It will work in some cases. But this means that it's not usable for $EDITOR, because there are cases where the editor may be executed with a relative pathname argument. In such a case, this argument should be handled normally if the directory still exists. Otherwise one should get either an error or the specified file (under Linux, one can still open relative pathnames starting with ../ even though the current working directory has been deleted), but getting another file is not acceptable. With a --chdir to $HOME, there is a high risk to get this wrong; to "/", the risk is lower, but still exists. Unfortunately, it isn't even possible to --chdir to the old path (obtained via /proc/$$/cwd under Linux), as the directory typically no longer exists when I need to do that, and Emacs cannot chdir to it, obviously. An option to set the default default-directory value and accept non-existing directories[*] would be more useful. [*] I suppose that this is not a problem since an existing directory can be removed after Emacs is started, so that the default-directory variable could point to a non-existing directory, and the current Emacs version is fine with that (things still work, and errors are reported gracefully). -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 15:39 ` Vincent Lefevre 2014-10-29 16:07 ` Eli Zaretskii @ 2014-10-29 16:15 ` Andreas Schwab 2014-10-29 16:51 ` Vincent Lefevre 2014-10-30 0:39 ` Stefan Monnier 2 siblings, 1 reply; 31+ messages in thread From: Andreas Schwab @ 2014-10-29 16:15 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 Vincent Lefevre <vincent@vinc17.net> writes: > emacs --eval '(setq default-directory nil) (find-file "~/out")' > > fails, but I wonder why. Try this: emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))' Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 16:15 ` Andreas Schwab @ 2014-10-29 16:51 ` Vincent Lefevre 2014-10-29 17:31 ` Andreas Schwab 0 siblings, 1 reply; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 16:51 UTC (permalink / raw) To: Andreas Schwab; +Cc: 18851 On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote: > Try this: > > emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))' Thanks. Now my question is: after starting Emacs like that, will there be any serious problem due to the fact that default-directory value is nil (except for the ~/out buffer)? -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 16:51 ` Vincent Lefevre @ 2014-10-29 17:31 ` Andreas Schwab 2014-10-29 17:45 ` Vincent Lefevre 0 siblings, 1 reply; 31+ messages in thread From: Andreas Schwab @ 2014-10-29 17:31 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 Vincent Lefevre <vincent@vinc17.net> writes: > On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote: >> Try this: >> >> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))' > > Thanks. Now my question is: after starting Emacs like that, will there > be any serious problem due to the fact that default-directory value is > nil (except for the ~/out buffer)? The global value of default-directory isn't actually used that much, new buffers inherit its value from the current buffer. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 17:31 ` Andreas Schwab @ 2014-10-29 17:45 ` Vincent Lefevre 2014-10-29 18:23 ` Ivan Shmakov 0 siblings, 1 reply; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 17:45 UTC (permalink / raw) To: Andreas Schwab; +Cc: 18851 On 2014-10-29 18:31:13 +0100, Andreas Schwab wrote: > Vincent Lefevre <vincent@vinc17.net> writes: > > > On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote: > >> Try this: > >> > >> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))' > > > > Thanks. Now my question is: after starting Emacs like that, will there > > be any serious problem due to the fact that default-directory value is > > nil (except for the ~/out buffer)? > > The global value of default-directory isn't actually used that much, new > buffers inherit its value from the current buffer. And what about the *scratch* buffer? Is this a problem like Eli said? If any, what problems? -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 17:45 ` Vincent Lefevre @ 2014-10-29 18:23 ` Ivan Shmakov 2014-10-29 21:11 ` Andreas Schwab 0 siblings, 1 reply; 31+ messages in thread From: Ivan Shmakov @ 2014-10-29 18:23 UTC (permalink / raw) To: 18851 >>>>> Vincent Lefevre <vincent@vinc17.net> writes: >>>>> On 2014-10-29 18:31:13 +0100, Andreas Schwab wrote: >>>>> Vincent Lefevre <vincent@vinc17.net> writes: >>>>> On 2014-10-29 17:15:45 +0100, Andreas Schwab wrote: >>>> Try this: >>>> emacs --eval '(progn (setq default-directory nil) (find-file "~/out"))' >>> Thanks. Now my question is: after starting Emacs like that, will >>> there be any serious problem due to the fact that default-directory >>> value is nil (except for the ~/out buffer)? >> The global value of default-directory isn't actually used that much, >> new buffers inherit its value from the current buffer. > And what about the *scratch* buffer? Is this a problem like Eli said? > If any, what problems? Should there be any issues with that, I guess an explicit M-x cd RET in that same *scratch* buffer will make them go away instantly. -- FSF associate member #7257 http://boycottsystemd.org/ … 3013 B6A0 230E 334A ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 18:23 ` Ivan Shmakov @ 2014-10-29 21:11 ` Andreas Schwab 0 siblings, 0 replies; 31+ messages in thread From: Andreas Schwab @ 2014-10-29 21:11 UTC (permalink / raw) To: Ivan Shmakov; +Cc: 18851 Ivan Shmakov <ivan@siamics.net> writes: > Should there be any issues with that, I guess an explicit > M-x cd RET in that same *scratch* buffer will make them go away > instantly. => error: Wrong type argument: stringp, nil Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 15:39 ` Vincent Lefevre 2014-10-29 16:07 ` Eli Zaretskii 2014-10-29 16:15 ` Andreas Schwab @ 2014-10-30 0:39 ` Stefan Monnier 2015-06-12 0:39 ` Glenn Morris 2 siblings, 1 reply; 31+ messages in thread From: Stefan Monnier @ 2014-10-30 0:39 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 > IMHO, if the current directory no longer exists, the default-directory > of *scratch* can be nil. Yes, that seems to be the right fix for this problem. Of course a default-directory set to nil can cause problems down the road, but these are either unavoidable or should likely be fixable. Stefan ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-30 0:39 ` Stefan Monnier @ 2015-06-12 0:39 ` Glenn Morris 2015-06-12 7:53 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2015-06-12 0:39 UTC (permalink / raw) To: Stefan Monnier; +Cc: Vincent Lefevre, 18851 Stefan Monnier wrote: >> IMHO, if the current directory no longer exists, the default-directory >> of *scratch* can be nil. > > Yes, that seems to be the right fix for this problem. > Of course a default-directory set to nil can cause problems down the > road, but these are either unavoidable or should likely be fixable. I installed something along these lines. Now: mkdir /tmp/foo cd /tmp/foo rmdir /tmp/foo emacs -Q works for me ~ 10% of the time. The rest of the time it segfaults. Does someone see what's missing? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2015-06-12 0:39 ` Glenn Morris @ 2015-06-12 7:53 ` Eli Zaretskii 2015-06-12 15:45 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2015-06-12 7:53 UTC (permalink / raw) To: Glenn Morris; +Cc: vincent, 18851 > From: Glenn Morris <rgm@gnu.org> > Cc: Vincent Lefevre <vincent@vinc17.net>, 18851@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org> > Date: Thu, 11 Jun 2015 20:39:04 -0400 > > Stefan Monnier wrote: > > >> IMHO, if the current directory no longer exists, the default-directory > >> of *scratch* can be nil. > > > > Yes, that seems to be the right fix for this problem. > > Of course a default-directory set to nil can cause problems down the > > road, but these are either unavoidable or should likely be fixable. > > I installed something along these lines. Now: > > mkdir /tmp/foo > cd /tmp/foo > rmdir /tmp/foo > emacs -Q > > works for me ~ 10% of the time. The rest of the time it segfaults. It doesn't segfault for me. Can you show a backtrace? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2015-06-12 7:53 ` Eli Zaretskii @ 2015-06-12 15:45 ` Glenn Morris 2015-06-12 19:31 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2015-06-12 15:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: vincent, 18851 Eli Zaretskii wrote: > It doesn't segfault for me. Can you show a backtrace? Here you go (maybe it's more like 50% than 10%): bt: #0 0x00007ffff12e2c45 in __memcpy_ssse3_back () from /lib64/libc.so.6 #1 0x00007ffff69df80d in SmcSetProperties () from /lib64/libSM.so.6 #2 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xeae5b0, clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0) at xsmfns.c:262 #3 0x00007ffff69e1c5d in _SmcProcessMessage () from /lib64/libSM.so.6 #4 0x00007ffff67d1b97 in IceProcessMessages () from /lib64/libICE.so.6 #5 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0) at xsmfns.c:110 #6 0x00000000006374ab in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:5087 #7 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2fe8, used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:3927 #8 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3500, used_mouse_menu=0x7fffffff394f) at keyboard.c:2200 #9 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3500, prev_event=..., used_mouse_menu=0x7fffffff394f) at keyboard.c:2265 #10 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:2875 #11 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b20, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9159 #12 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407 #13 0x00000000005e229a in internal_condition_case ( bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>) at eval.c:1348 #14 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139 #15 0x00000000005e1a2d in internal_catch (tag=..., func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108 #16 0x000000000054859a in command_loop () at keyboard.c:1118 #17 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728 #18 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799 #19 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3fe8) at emacs.c:1626 bt full: #0 0x00007ffff12e2c45 in __memcpy_ssse3_back () from /lib64/libc.so.6 No symbol table info available. #1 0x00007ffff69df80d in SmcSetProperties () from /lib64/libSM.so.6 No symbol table info available. #2 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xeae5b0, clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0) at xsmfns.c:262 props = {0x7fffffff2830, 0x7fffffff2850, 0x7fffffff2870, 0x7fffffff2890, 0xeaf100} prop_ptr = {{ name = 0x14d52c0 "CloneCommand", type = 0xd69190 "LISTofARRAY8", num_vals = 1, vals = 0x7fffffff26f0 }, { name = 0xe6ca50 "Program", type = 0x11c4820 "ARRAY8", num_vals = 1, vals = 0x7fffffff2700 }, { name = 0xd537a0 "UserID", type = 0xe6cf10 "ARRAY8", num_vals = 1, vals = 0x7fffffff2710 }, { name = 0xd55160 "RestartCommand", type = 0xdb2390 "LISTofARRAY8", num_vals = 5, vals = 0xe7e640 }, { name = 0x7fffffff28c0 "\020$|\366\377\177", type = 0x4860ff6efdd1c200 <Address 0x4860ff6efdd1c200 out of bounds>, num_vals = -159636464, vals = 0x7ffff7fc6000 }} values = {{ length = 45, value = 0xeaed30 }, { length = 5, value = 0xe647c0 }, { length = 7, value = 0xe61940 }, { length = 15820013, value = 0x1 }, { length = 500000000, value = 0x7ffff7de44c9 <check_match.9344+89> }, { length = 0, value = 0x7ffff67c16a8 }, { length = 10, value = 0x5b }, { length = -456570963, value = 0x7ffff7de4ccb <do_lookup_x+1803> }, { length = 499658979, value = 0x7fffffff27b0 }, { length = -159640236, value = 0x7ffff67c2410 }, { length = -55104, value = 0x7fffffff28b0 }, { length = 45, value = 0x5341d }, { length = 0, value = 0x0 }, { length = -134455296, value = 0x406e31 }, { length = -159634424, value = 0x403e10 }, { length = 0, value = 0x10000008f }, { length = 20813427, value = 0x7fffffff2978 }, { length = -54960, value = 0x1 }, { length = 16, value = 0x7fffffff2910 }, { length = -55248, value = 0x4860ff6efdd1c200 }} vp = 0xe7e640 val_idx = 3 vp_idx = 4 props_idx = 4 i = 2 smid_opt = 0xe0e010 "--smid=2d8bff4ea-7fc2-496f-bf2b-dd182557f83d" chdir_opt = 0x0 user_login_name = { i = 18641748 } cwd = 0x0 #3 0x00007ffff69e1c5d in _SmcProcessMessage () from /lib64/libSM.so.6 No symbol table info available. #4 0x00007ffff67d1b97 in IceProcessMessages () from /lib64/libICE.so.6 No symbol table info available. #5 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0) at xsmfns.c:110 ret = 11 #6 0x00000000006374ab in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:5087 d = 0xc5cde8 <fd_callback_info+264> timeout_reduced_for_timers = true channel = 11 nfds = 2 Available = { fds_bits = {3072, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = { i = 0 } timeout = { tv_sec = 0, tv_nsec = 0 } end_time = { tv_sec = 0, tv_nsec = 0 } got_some_input = -1 count = 2 #7 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2fe8, used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:3927 do_display = true obj = { i = 0 } #8 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3500, used_mouse_menu=0x7fffffff394f) at keyboard.c:2200 c = { i = 0 } save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 <repeats 16 times>} } }} kb = 0x1dcd6500 #9 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3500, prev_event=..., used_mouse_menu=0x7fffffff394f) at keyboard.c:2265 nextevt = { i = 13589501 } frame = 0x7fffffff3260 terminal = 0xcf5bfd events = {{ i = 13076624 }, { i = 0 }, { i = 0 }, { i = 140737488302560 }, { i = 5506081 }, { i = 499992607 }, { i = 140737488302624 }, { i = 5560959 }, { i = 13076624 }, { i = 4294967296 }, { i = 0 }, { i = 140737488302624 }, { i = 5506081 }, { i = 0 }, { i = 140737488302672 }, { i = 5587002 }} n = 0 #10 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffff394f, end_time=0x0) at keyboard.c:2875 c = { i = 0 } jmpcount = 2 local_getcjmp = {{ __jmpbuf = {0, -601185235832345470, 19028509, 43008, 0, 0, -601185235687641982, 601184789779639426}, __mask_was_saved = 0, __saved_mask = { __val = {140737488303456, 5506081, 0, 140737488303744, 5643396, 0, 0, 43008, 0, 0, 0, 0, 0, 0, 0, 0} } }} save_jump = {{ __jmpbuf = {17083104, 18474576, 0, 13627136, 20957107, 17083104, 13076624, 0}, __mask_was_saved = 5397952, __saved_mask = { __val = {140737488303248, 13076624, 0, 140737488303456, 140737488303280, 5506081, 0, 140737488303456, 6187899, 0, 2, 0, 6601013, 0, 5506321, 5397952} } }} tem = { i = 774368 } save = { i = 0 } previous_echo_area_message = { i = 0 } also_record = { i = 0 } reread = false gcpro1 = { next = 0xcfef45, var = 0x7020, nvars = 140737488303248 } gcpro2 = { next = 0xc78890 <lispsym>, var = 0xcfef40, nvars = 140737488303072 } polling_stopped_here = true orig_kboard = 0xea8ae0 #11 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b20, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9159 interrupted_kboard = 0xea8ae0 interrupted_frame = 0x12d7830 key = { i = 140737488304528 } used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = { i = 1 } count = 2 t = 0 echo_start = 0 keys_start = 0 current_binding = { i = 17376275 } first_event = { i = 0 } first_unbound = 31 mock_input = 0 fkey = { parent = { i = 17494291 }, map = { i = 17494291 }, start = 0, end = 0 } keytran = { parent = { i = 13581891 }, map = { i = 13581891 }, start = 0, end = 0 } indec = { parent = { i = 17494307 }, map = { i = 17494307 }, start = 0, end = 0 } shift_translated = false delayed_switch_frame = { i = 0 } original_uppercase = { i = 140737488304704 } original_uppercase_position = -1 dummyflag = false starting_buffer = 0xcfef40 fake_prefixed_keys = { i = 0 } gcpro1 = { next = 0xc78890 <lispsym>, var = 0x0, nvars = 13674661 } #12 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407 cmd = { i = 140737488305248 } keybuf = {{ i = 0 }, { i = 4274848 }, { i = 13076624 }, { i = 0 }, { i = 0 }, { i = 140737488304992 }, { i = 5506081 }, { i = 0 }, { i = 140737488305168 }, { i = 6187899 }, { i = 16935731 }, { i = 2 }, { i = 0 }, { i = 12914144 }, { i = 8350928 }, { i = 0 }, { i = 16935731 }, { i = 13104320 }, { i = 10674453 }, { i = 21807312 }, { i = 140737488305168 }, { i = 6186898 }, { i = 3 }, { i = 140737488305136 }, { i = 27696 }, { i = 27696 }, { i = 0 }, { i = 13104320 }, { i = 4274848 }, { i = 0 }} i = 0 prev_modiff = 0 prev_buffer = 0x0 already_adjusted = false #13 0x00000000005e229a in internal_condition_case ( bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>) at eval.c:1348 val = { i = 16935731 } c = 0xe6b410 #14 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139 val = { i = 15119072 } #15 0x00000000005e1a2d in internal_catch (tag=..., func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108 val = { i = 0 } c = 0xe6b2e0 #16 0x000000000054859a in command_loop () at keyboard.c:1118 No locals. #17 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728 count = 1 val = { i = 140737488305600 } #18 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799 count = 0 buffer = { i = 0 } #19 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3fe8) at emacs.c:1626 dummy = { i = 80 } stack_bottom_variable = 0 '\000' do_initial_setlocale = true dumping = false skip_args = 0 rlim = { rlim_cur = 33554432, rlim_max = 18446744073709551615 } no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 A debugging session is active. Inferior 1 [process 6488] will be killed. Quit anyway? (y or n) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2015-06-12 15:45 ` Glenn Morris @ 2015-06-12 19:31 ` Eli Zaretskii 2015-06-13 1:29 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2015-06-12 19:31 UTC (permalink / raw) To: Glenn Morris; +Cc: vincent, 18851 > From: Glenn Morris <rgm@gnu.org> > Cc: monnier@iro.umontreal.ca, vincent@vinc17.net, 18851@debbugs.gnu.org > Date: Fri, 12 Jun 2015 11:45:18 -0400 > > Eli Zaretskii wrote: > > > It doesn't segfault for me. Can you show a backtrace? > > Here you go (maybe it's more like 50% than 10%): > > bt: > > #0 0x00007ffff12e2c45 in __memcpy_ssse3_back () from /lib64/libc.so.6 > #1 0x00007ffff69df80d in SmcSetProperties () from /lib64/libSM.so.6 > #2 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xeae5b0, > clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0) > at xsmfns.c:262 Maybe SMC cannot work with current directory removed? ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2015-06-12 19:31 ` Eli Zaretskii @ 2015-06-13 1:29 ` Glenn Morris 2015-06-13 7:56 ` Eli Zaretskii 0 siblings, 1 reply; 31+ messages in thread From: Glenn Morris @ 2015-06-13 1:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: vincent, 18851 Eli Zaretskii wrote: > Maybe SMC cannot work with current directory removed? It looks that way, though xsmfns.c already seems to take the necessary precautions for that case, and a super-quick look at the libSM source didn't show any obvious issue. The only solution I can think of is to disable session-management in such a case: --- a/src/xsmfns.c +++ b/src/xsmfns.c @@ -28,6 +28,7 @@ along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>. */ #include <unistd.h> #include <sys/param.h> +#include <errno.h> #include <stdio.h> #include "lisp.h" @@ -402,6 +403,14 @@ x_session_initialize (struct x_display_info *dpyinfo) SmcCallbacks callbacks; ptrdiff_t name_len = 0; + /* libSM seems to crash if pwd is missing - see bug#18851. */ + if (! get_current_dir_name ()) + { + fprintf (stderr, "Disabling session management due to pwd error: %s\n", + emacs_strerror (errno)); + return; + } + ice_fd = -1; doing_interact = false; For completeness, here's a backtrace with debug libSM and libICE included. (What about the address-out-of-bounds in #3?) bt: #0 0x00007ffff12e5640 in __memcpy_ssse3_back () from /lib64/libc.so.6 #1 0x00007ffff69df80d in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=0x15b675c) at /usr/include/bits/string3.h:51 #2 SmcSetProperties (smcConn=<optimized out>, numProps=4, props=0x7fffffff28e0) at sm_client.c:379 #3 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xea0370, clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0) at xsmfns.c:262 #4 0x00007ffff69e1c5d in _SmcProcessMessage (iceConn=0xea0f90, clientData=0xea0370, opcode=<optimized out>, length=<optimized out>, swap=0, replyWait=<optimized out>, replyReadyRet=0x7fffffff2a00) at sm_process.c:241 #5 0x00007ffff67d1b97 in IceProcessMessages (iceConn=0xea0f90, replyWait=0x0, replyReadyRet=0x0) at process.c:386 #6 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0) at xsmfns.c:110 #7 0x0000000000637484 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:5081 #8 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2ff8, used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:3927 #9 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3510, used_mouse_menu=0x7fffffff395f) at keyboard.c:2200 #10 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3510, prev_event=..., used_mouse_menu=0x7fffffff395f) at keyboard.c:2265 #11 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:2875 #12 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b30, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9159 #13 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407 #14 0x00000000005e229a in internal_condition_case ( bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>) at eval.c:1348 #15 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139 #16 0x00000000005e1a2d in internal_catch (tag=..., func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108 #17 0x000000000054859a in command_loop () at keyboard.c:1118 #18 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728 #19 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799 #20 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3ff8) at emacs.c:1626 #0 0x00007ffff12e5640 in __memcpy_ssse3_back () from /lib64/libc.so.6 bt full: #1 0x00007ffff69df80d in memcpy (__len=<optimized out>, __src=<optimized out>, __dest=0x15b675c) at /usr/include/bits/string3.h:51 No locals. #2 SmcSetProperties (smcConn=<optimized out>, numProps=4, props=0x7fffffff28e0) at sm_client.c:379 _i = <optimized out> _j = 4 iceConn = 0xea0f90 pMsg = <optimized out> pBuf = 0x15b675c "" pStart = 0x15b65d0 "\004" bytes = 400 #3 0x0000000000536f5b in smc_save_yourself_CB (smcConn=0xea0370, clientData=0x0, saveType=1, shutdown=0, interactStyle=0, fast=0) at xsmfns.c:262 props = {0x7fffffff2840, 0x7fffffff2860, 0x7fffffff2880, 0x7fffffff28a0, 0xea0a00} prop_ptr = {{ name = 0xd887e0 "CloneCommand", type = 0xda4930 "LISTofARRAY8", num_vals = 1, vals = 0x7fffffff2700 }, { name = 0xe733b0 "Program", type = 0xea0ba0 "ARRAY8", num_vals = 1, vals = 0x7fffffff2710 }, { name = 0xf533a0 "UserID", type = 0xf54070 "ARRAY8", num_vals = 1, vals = 0x7fffffff2720 }, { name = 0xf54150 "RestartCommand", type = 0xf54230 "LISTofARRAY8", num_vals = 5, vals = 0x1008d10 }, { name = 0x7fffffff28d0 "\020$|\366\377\177", type = 0x712665236f658c00 <Address 0x712665236f658c00 out of bounds>, num_vals = -159636464, vals = 0x7ffff7fc6000 }} values = {{ length = 45, value = 0xea1460 }, { length = 5, value = 0xe64690 }, { length = 7, value = 0xe61810 }, { length = 20421677, value = 0x1 }, { length = 500000000, value = 0x7ffff7de44c9 <check_match.9344+89> }, { length = 0, value = 0x7ffff67c16a8 }, { length = 10, value = 0x5b }, { length = -456570963, value = 0x7ffff7de4ccb <do_lookup_x+1803> }, { length = 499925475, value = 0x7fffffff27c0 }, { length = -159640236, value = 0x7ffff67c2410 }, { length = -55088, value = 0x7fffffff28c0 }, { length = 45, value = 0x1231d }, { length = 0, value = 0x0 }, { length = -134455296, value = 0x406e31 }, { length = -159634424, value = 0x403e10 }, { length = 0, value = 0x10000008f }, { length = 17519331, value = 0x7fffffff2988 }, { length = -54944, value = 0x1 }, { length = 16, value = 0x7fffffff2920 }, { length = -55232, value = 0x712665236f658c00 }} vp = 0x1008d10 val_idx = 3 vp_idx = 4 props_idx = 4 i = 2 smid_opt = 0xf2c690 "--smid=26667490d-357a-48ea-b51a-9851440ed37c" chdir_opt = 0x0 user_login_name = { i = 18634644 } cwd = 0x0 #4 0x00007ffff69e1c5d in _SmcProcessMessage (iceConn=0xea0f90, clientData=0xea0370, opcode=<optimized out>, length=<optimized out>, swap=0, replyWait=<optimized out>, replyReadyRet=0x7fffffff2a00) at sm_process.c:241 pMsg = 0xea4910 errVal = 0 '\000' errOffset = -1 smcConn = <optimized out> #5 0x00007ffff67d1b97 in IceProcessMessages (iceConn=0xea0f90, replyWait=0x0, replyReadyRet=0x0) at process.c:386 processProc = <optimized out> processMsgInfo = <optimized out> header = 0xea4910 replyReady = 0 useThisReplyWait = 0x0 retStatus = IceProcessMessagesSuccess #6 0x00000000005367d5 in x_session_check_input (fd=11, data=0x0) at xsmfns.c:110 ret = 11 #7 0x0000000000637484 in wait_reading_process_output (time_limit=0, nsecs=0, read_kbd=-1, do_display=true, wait_for_cell=..., wait_proc=0x0, just_wait_proc=0) at process.c:5081 d = 0xc5cde8 <fd_callback_info+264> timeout_reduced_for_timers = true channel = 11 nfds = 1 Available = { fds_bits = {2048, 0 <repeats 15 times>} } Writeok = { fds_bits = {0 <repeats 16 times>} } check_write = true check_delay = 0 no_avail = false xerrno = 11 proc = { i = 0 } timeout = { tv_sec = 0, tv_nsec = 499969517 } end_time = { tv_sec = 5506081, tv_nsec = 0 } got_some_input = -1 count = 2 #8 0x000000000054e66b in kbd_buffer_get_event (kbp=0x7fffffff2ff8, used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:3927 do_display = true obj = { i = 0 } #9 0x000000000054ac3e in read_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3510, used_mouse_menu=0x7fffffff395f) at keyboard.c:2200 c = { i = 0 } save_jump = {{ __jmpbuf = {0, 0, 0, 0, 0, 0, 0, 0}, __mask_was_saved = 0, __saved_mask = { __val = {0 <repeats 16 times>} } }} kb = 0x1dcd6500 #10 0x000000000054aea3 in read_decoded_event_from_main_queue (end_time=0x0, local_getcjmp=0x7fffffff3510, prev_event=..., used_mouse_menu=0x7fffffff395f) at keyboard.c:2265 nextevt = { i = 13589501 } frame = 0x7fffffff3270 terminal = 0xcf5bfd events = {{ i = 13076624 }, { i = 0 }, { i = 0 }, { i = 140737488302576 }, { i = 5506081 }, { i = 499988655 }, { i = 140737488302640 }, { i = 5560959 }, { i = 13076624 }, { i = 4294967296 }, { i = 0 }, { i = 140737488302640 }, { i = 5506081 }, { i = 0 }, { i = 140737488302688 }, { i = 5587002 }} n = 0 #11 0x000000000054c421 in read_char (commandflag=1, map=..., prev_event=..., used_mouse_menu=0x7fffffff395f, end_time=0x0) at keyboard.c:2875 c = { i = 0 } jmpcount = 2 local_getcjmp = {{ __jmpbuf = {0, -2368210174059533009, 17161965, 43008, 0, 0, -2368210174200042193, 2368209730108206383}, __mask_was_saved = 0, __saved_mask = { __val = {140737488303472, 5506081, 0, 140737488303760, 5643396, 0, 0, 43008, 0, 566608, 0, 0, 0, 12476142, 9644764, 12476117} } }} save_jump = {{ __jmpbuf = {16844352, 18467472, 5390848, 13627136, 20960179, 16844352, 13076624, 0}, __mask_was_saved = 5390848, __saved_mask = { __val = {140737488303264, 13076624, 0, 140737488303472, 140737488303296, 5506081, 0, 140737488303472, 6187899, 0, 2, 0, 6600973, 0, 5506321, 5390848} } }} tem = { i = 774368 } save = { i = 0 } previous_echo_area_message = { i = 0 } also_record = { i = 0 } reread = false gcpro1 = { next = 0x7fffffff3400, var = 0x540614 <CAR_SAFE+47>, nvars = 21474836480 } gcpro2 = { next = 0xc78890 <lispsym>, var = 0x7fffffff33e0, nvars = 5506081 } polling_stopped_here = true orig_kboard = 0xe9ab20 #12 0x0000000000558b68 in read_key_sequence (keybuf=0x7fffffff3b30, bufsize=30, prompt=..., dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9159 interrupted_kboard = 0xe9ab20 interrupted_frame = 0x12d3c50 key = { i = 140737488304592 } used_mouse_menu = false echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 new_binding = { i = 5510211 } count = 2 t = 0 echo_start = 0 keys_start = 0 current_binding = { i = 17524643 } first_event = { i = 0 } first_unbound = 31 mock_input = 0 fkey = { parent = { i = 17364467 }, map = { i = 17364467 }, start = 0, end = 0 } keytran = { parent = { i = 13581891 }, map = { i = 13581891 }, start = 0, end = 0 } indec = { parent = { i = 17364547 }, map = { i = 17364547 }, start = 0, end = 0 } shift_translated = false delayed_switch_frame = { i = 0 } original_uppercase = { i = 13076624 } original_uppercase_position = -1 dummyflag = false starting_buffer = 0xcfef40 fake_prefixed_keys = { i = 0 } gcpro1 = { next = 0x0, var = 0x54a6a4 <safe_run_hook_funcall+93>, nvars = 26832 } #13 0x0000000000548d11 in command_loop_1 () at keyboard.c:1407 cmd = { i = 140737488305264 } keybuf = {{ i = 0 }, { i = 4274848 }, { i = 13076624 }, { i = 0 }, { i = 0 }, { i = 140737488305008 }, { i = 5506081 }, { i = 0 }, { i = 140737488305184 }, { i = 6187899 }, { i = 16933475 }, { i = 2 }, { i = 0 }, { i = 12914144 }, { i = 8354000 }, { i = 0 }, { i = 16933475 }, { i = 13104320 }, { i = 10674493 }, { i = 21808368 }, { i = 140737488305184 }, { i = 6186898 }, { i = 3 }, { i = 140737488305152 }, { i = 27696 }, { i = 27696 }, { i = 0 }, { i = 13104320 }, { i = 4274848 }, { i = 0 }} i = 0 prev_modiff = 0 prev_buffer = 0x0 already_adjusted = false #14 0x00000000005e229a in internal_condition_case ( bfun=0x5488f2 <command_loop_1>, handlers=..., hfun=0x5480d7 <cmd_error>) at eval.c:1348 val = { i = 16933475 } c = 0xe6b410 #15 0x00000000005485fa in command_loop_2 (ignore=...) at keyboard.c:1139 val = { i = 15119072 } #16 0x00000000005e1a2d in internal_catch (tag=..., func=0x5485d1 <command_loop_2>, arg=...) at eval.c:1108 val = { i = 0 } c = 0xe6b2e0 #17 0x000000000054859a in command_loop () at keyboard.c:1118 No locals. #18 0x0000000000547cb2 in recursive_edit_1 () at keyboard.c:728 count = 1 val = { i = 140737488305616 } #19 0x0000000000547e3c in Frecursive_edit () at keyboard.c:799 count = 0 buffer = { i = 0 } #20 0x0000000000545c0f in main (argc=2, argv=0x7fffffff3ff8) at emacs.c:1626 dummy = { i = 80 } stack_bottom_variable = 0 '\000' do_initial_setlocale = true dumping = false skip_args = 0 rlim = { rlim_cur = 33554432, rlim_max = 18446744073709551615 } no_loadup = false junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 original_pwd = 0x0 A debugging session is active. Inferior 1 [process 3610] will be killed. Quit anyway? (y or n) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2015-06-13 1:29 ` Glenn Morris @ 2015-06-13 7:56 ` Eli Zaretskii 2015-06-13 23:45 ` Glenn Morris 0 siblings, 1 reply; 31+ messages in thread From: Eli Zaretskii @ 2015-06-13 7:56 UTC (permalink / raw) To: Glenn Morris; +Cc: vincent, 18851 > From: Glenn Morris <rgm@gnu.org> > Cc: monnier@iro.umontreal.ca, vincent@vinc17.net, 18851@debbugs.gnu.org > Date: Fri, 12 Jun 2015 21:29:05 -0400 > > Eli Zaretskii wrote: > > > Maybe SMC cannot work with current directory removed? > > It looks that way, though xsmfns.c already seems to take the necessary > precautions for that case, and a super-quick look at the libSM source > didn't show any obvious issue. The only solution I can think of is to > disable session-management in such a case: I think you should install this. After all, how frequent is this scenario that we should bother about session-management in that case? > For completeness, here's a backtrace with debug libSM and libICE included. > (What about the address-out-of-bounds in #3?) props[4] is garbage, because there are only 4 valid elements in this case (props_idx = 4). So it's just GDB displaying a garbled 5th element of props[] array. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2015-06-13 7:56 ` Eli Zaretskii @ 2015-06-13 23:45 ` Glenn Morris 0 siblings, 0 replies; 31+ messages in thread From: Glenn Morris @ 2015-06-13 23:45 UTC (permalink / raw) To: Eli Zaretskii; +Cc: vincent, 18851 Eli Zaretskii wrote: > I think you should install this. After all, how frequent is this > scenario that we should bother about session-management in that case? Agreed & installed. Starting Emacs with PWD deleted now works. The basics (M-x cd, find-file) work, but I'm sure there are many places that do not expect default-directory to be nil. I doubt it is worth correcting them all. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 8:09 ` Vincent Lefevre 2014-10-29 12:57 ` Stefan Monnier @ 2014-10-29 14:23 ` Eli Zaretskii 2014-10-29 15:39 ` Andreas Schwab 2014-10-29 16:05 ` Vincent Lefevre 1 sibling, 2 replies; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 14:23 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 > Date: Wed, 29 Oct 2014 09:09:39 +0100 > From: Vincent Lefevre <vincent@vinc17.net> > Cc: rgm@gnu.org, 18851@debbugs.gnu.org > > > Because Emacs needs to pretend to the user that it runs _in_ that > > directory, so that relative file names work as you'd expect. > > I don't expect anything about reative file names. But if I type > "emacs foo", opening file "foo" from $HOME would be bad. > > > In this regard, Emacs is like the shell. > > The shell has no problems when the current directory has been > removed. It can still run without needing to switch to $HOME. We are in violent agreement here. I wasn't advocating to change to HOME instead; quite the contrary: Glenn asked whether doing so is worth the trouble, and I replied that I didn't think so. > > > Note that the current directory can also be removed after Emacs > > > is started, so I expect that Emacs already supports cases like > > > that. > > > > No, it does not. Either the OS leaves the directory in existence > > until Emacs exits, or the OS prevents you from removing it. > > Linux does neither. AFAIK, GNU/Linux does the former. The directory is not physically removed until the last process that has an open file descriptor for it closes that descriptor. Any attempts to reference that directory for obtaining a new descriptor will get ENOENT, i.e. the OS pretends that the directory doesn't exist. But existing descriptors are valid, and can be used as usual. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 14:23 ` Eli Zaretskii @ 2014-10-29 15:39 ` Andreas Schwab 2014-10-29 16:00 ` Eli Zaretskii 2014-10-29 16:05 ` Vincent Lefevre 1 sibling, 1 reply; 31+ messages in thread From: Andreas Schwab @ 2014-10-29 15:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Vincent Lefevre, 18851 Eli Zaretskii <eliz@gnu.org> writes: >> > > Note that the current directory can also be removed after Emacs >> > > is started, so I expect that Emacs already supports cases like >> > > that. >> > >> > No, it does not. Either the OS leaves the directory in existence >> > until Emacs exits, or the OS prevents you from removing it. >> >> Linux does neither. > > AFAIK, GNU/Linux does the former. The directory is not physically > removed until the last process that has an open file descriptor for it > closes that descriptor. Any attempts to reference that directory for > obtaining a new descriptor will get ENOENT, i.e. the OS pretends that > the directory doesn't exist. But existing descriptors are valid, and > can be used as usual. "As usual" is an exaggeration. Basically the only valid operations on it are fstat and fchdir. Any attempt at adding an entry to it (via openat) will be rejected. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 15:39 ` Andreas Schwab @ 2014-10-29 16:00 ` Eli Zaretskii 0 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 16:00 UTC (permalink / raw) To: Andreas Schwab; +Cc: vincent, 18851 > From: Andreas Schwab <schwab@suse.de> > Cc: Vincent Lefevre <vincent@vinc17.net>, 18851@debbugs.gnu.org > Date: Wed, 29 Oct 2014 16:39:22 +0100 > > > AFAIK, GNU/Linux does the former. The directory is not physically > > removed until the last process that has an open file descriptor for it > > closes that descriptor. Any attempts to reference that directory for > > obtaining a new descriptor will get ENOENT, i.e. the OS pretends that > > the directory doesn't exist. But existing descriptors are valid, and > > can be used as usual. > > "As usual" is an exaggeration. Basically the only valid operations on > it are fstat and fchdir. Any attempt at adding an entry to it (via > openat) will be rejected. Yes, any attempt to add descriptors will fail. By "as usual" I meant using the descriptor to extract information, like fstat, readdir, etc. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 14:23 ` Eli Zaretskii 2014-10-29 15:39 ` Andreas Schwab @ 2014-10-29 16:05 ` Vincent Lefevre 2014-10-29 16:21 ` Eli Zaretskii 1 sibling, 1 reply; 31+ messages in thread From: Vincent Lefevre @ 2014-10-29 16:05 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 18851 On 2014-10-29 16:23:24 +0200, Eli Zaretskii wrote: > > > > Note that the current directory can also be removed after Emacs > > > > is started, so I expect that Emacs already supports cases like > > > > that. > > > > > > No, it does not. Either the OS leaves the directory in existence > > > until Emacs exits, or the OS prevents you from removing it. > > > > Linux does neither. > > AFAIK, GNU/Linux does the former. Not really... > The directory is not physically removed until the last process that > has an open file descriptor for it closes that descriptor. OK, but if the only reference is the current working directory, it isn't usable at all. Nevertheless, Emacs won't quit because of that. -- Vincent Lefèvre <vincent@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-29 16:05 ` Vincent Lefevre @ 2014-10-29 16:21 ` Eli Zaretskii 0 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 16:21 UTC (permalink / raw) To: Vincent Lefevre; +Cc: 18851 > Date: Wed, 29 Oct 2014 17:05:00 +0100 > From: Vincent Lefevre <vincent@vinc17.net> > Cc: rgm@gnu.org, 18851@debbugs.gnu.org > > > The directory is not physically removed until the last process that > > has an open file descriptor for it closes that descriptor. > > OK, but if the only reference is the current working directory, > it isn't usable at all. It is usable for a limited set of operations, as was mentioned in previous messages. > Nevertheless, Emacs won't quit because of that. Right. ^ permalink raw reply [flat|nested] 31+ messages in thread
* bug#18851: 24.4; emacs cannot be started if the current directory has been removed 2014-10-28 21:34 ` Glenn Morris 2014-10-29 1:28 ` Vincent Lefevre @ 2014-10-29 3:40 ` Eli Zaretskii 2014-10-29 10:57 ` Emacs bugs at the Debian BTS Ivan Shmakov 2 siblings, 0 replies; 31+ messages in thread From: Eli Zaretskii @ 2014-10-29 3:40 UTC (permalink / raw) To: Glenn Morris; +Cc: vincent, 18851 > From: Glenn Morris <rgm@gnu.org> > Date: Tue, 28 Oct 2014 17:34:59 -0400 > Cc: 18851@debbugs.gnu.org > > So is it worth it? No, not IMO. I don't really see the practical use case behind this bug. ^ permalink raw reply [flat|nested] 31+ messages in thread
* Emacs bugs at the Debian BTS 2014-10-28 21:34 ` Glenn Morris 2014-10-29 1:28 ` Vincent Lefevre 2014-10-29 3:40 ` Eli Zaretskii @ 2014-10-29 10:57 ` Ivan Shmakov 2 siblings, 0 replies; 31+ messages in thread From: Ivan Shmakov @ 2014-10-29 10:57 UTC (permalink / raw) To: emacs-devel >>>>> Glenn Morris <rgm@gnu.org> writes: >>>>> Vincent Lefevre wrote: [Dropping Cc: 18851@debbugs.gnu.org.] […] >> My old bug report in the Debian BTS: >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=687171 > IMO there's really no point reporting Emacs problems that aren't > specific to Debian (and this issues obviously isn't) to the Debian > bug tracker. I tend to disagree. First of all, strictly speaking, there’s no easy way for the user to tell if the problem is specific to Debian or not, except for building a version of Emacs directly from the GNU sources, – and at least /some/ of the Emacs users wouldn’t go through the trouble. Also (to state the obvious), as it’s the state of the /Debian packages/ that Debian BTS tracks, it’s easier to determine if an upgrade would resolve any particular issue by looking there, rather than at the upstream BTS. > They just sit there for some lengthy period of time, and only if they > get forwarded here does something happen. (Although I do look at the > Debian Emacs bug reports and had looked at that one.) Indeed, that could be improved. However, anyone’s free to bring an issue of their choice to the attention of the upstream developers, so that’s just the matter of paying some attention to the task. Perhaps Debian would benefit from reminding the users to take these steps on their own (as part of the BTS acknowledgment message, for instance), but it seem otherwise an obvious thing for an (experienced) user to do, anyway. […] -- FSF associate member #7257 np. Фейерверк — Гражданская Оборона … 230E 334A ^ permalink raw reply [flat|nested] 31+ messages in thread
end of thread, other threads:[~2015-06-13 23:45 UTC | newest] Thread overview: 31+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2014-10-27 13:33 bug#18851: 24.4; emacs cannot be started if the current directory has been removed Vincent Lefevre 2014-10-28 21:34 ` Glenn Morris 2014-10-29 1:28 ` Vincent Lefevre 2014-10-29 3:50 ` Eli Zaretskii 2014-10-29 8:09 ` Vincent Lefevre 2014-10-29 12:57 ` Stefan Monnier 2014-10-29 14:27 ` Eli Zaretskii 2014-10-29 15:39 ` Vincent Lefevre 2014-10-29 16:07 ` Eli Zaretskii 2014-10-29 16:44 ` Vincent Lefevre 2014-10-29 16:15 ` Andreas Schwab 2014-10-29 16:51 ` Vincent Lefevre 2014-10-29 17:31 ` Andreas Schwab 2014-10-29 17:45 ` Vincent Lefevre 2014-10-29 18:23 ` Ivan Shmakov 2014-10-29 21:11 ` Andreas Schwab 2014-10-30 0:39 ` Stefan Monnier 2015-06-12 0:39 ` Glenn Morris 2015-06-12 7:53 ` Eli Zaretskii 2015-06-12 15:45 ` Glenn Morris 2015-06-12 19:31 ` Eli Zaretskii 2015-06-13 1:29 ` Glenn Morris 2015-06-13 7:56 ` Eli Zaretskii 2015-06-13 23:45 ` Glenn Morris 2014-10-29 14:23 ` Eli Zaretskii 2014-10-29 15:39 ` Andreas Schwab 2014-10-29 16:00 ` Eli Zaretskii 2014-10-29 16:05 ` Vincent Lefevre 2014-10-29 16:21 ` Eli Zaretskii 2014-10-29 3:40 ` Eli Zaretskii 2014-10-29 10:57 ` Emacs bugs at the Debian BTS Ivan Shmakov
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.