A normal lock file is apparently 1024 bytes in size, so the second
attempt at reading bytes from the file would try to read 8192 more
bytes into a buffer that has room for only 7168 left. According to
valgrind, the read() function doesn't like that -- and true: if for
some reason the lock file had suddenly expanded, the buffer would
overflow.
This fixes https://savannah.gnu.org/bugs/?47156.
Commit 36ec76a made the wrong change: after a tab that did not list any
file names on the screen, a refresh /is/ needed, because a previous tab
might have listed things on the screen. But at the end of the prompt,
it is not necessary to refresh the edit window if things were listed,
because the window will be refreshed anyway after reading in a file.
Use 'slash' to point at a possible slash, use 'filename' just to
point at the real file name, and use 'wasdirname' just to point at
the dir's name before expanding it in order to be able to free it.
Also, remove two superfluous asserts: 'dirname' cannot be NULL
because it has just been mallocstrcpy'd, and checking 'num_matches'
is pointless as it would crash on the next statement anyway.
This is a remnant from 2001, when things were different. Now, there
is no need to refresh the edit window when tabbing produced no list.
When it did produce a list, it is cleared off later.
If for some reason opening the spell-checked or formatted file fails,
don't throw away the current contents of the buffer.
(It should also give proper feedback about the failure, but we'll leave
that for some other time.)
Also, store the input character earlier, so we don't have to use len - 1.
Furthermore, len increments in steps of 1, so it cannot pass the value of
bufx unnoticed, so use a comparison for equality.
Most of the time NO_CONVERT will not be set, the number of lines will
not be zero, and the format of the file will be zero. Rearrange the
conditions so that they will evaluate as FALSE as soon as possible.
Index i follows almost synchronously the value of len. Since we're
adding characters to the intermediate buffer always only at the end,
just use len as the index.
Until now (when not leaving files unconverted), nano would fumble and
drop the final carriage return of a Mac file, and would thus treat the
last line of such a file as an unterminated line and prepend it to the
current line of the buffer. Correct that, and delete the dead piece
of code that was meant to do this.
This fixes https://savannah.gnu.org/bugs/?47716.
When we don't set edittop in read_line(), we don't need to readjust it in
read_file(), because in that particular case it will still be pointing at
current. And since fileptr is a new, freshly created line, it can never
be equal to filebot, so there is no point in comparing them.
If more than one line was inserted at the beginning of the file, leave it
up to the screen handling to set edittop to what it should be.
Move the setting of fileage a bit down, to its sister setting: the line
at current gets "connected" either to the top-of-file pointer or to the
last line of the inserted file.
(This change will be made superfluous when we start using gnulib.)
This prevents getcwd() from failing on Android and thus completes the
fix for https://savannah.gnu.org/bugs/index.php?47659.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Doing a chdir("..") will not fail when the root directory is reached,
and when getcwd() keeps failing too, we have no way of knowing when
to stop. So, simply limit the number of attempted chdirs, to avoid
getting into an endless loop.
This avoids the hang in https://savannah.gnu.org/bugs/index.php?47659.
Reported-by: Chris Renshaw <osm0sis@outlook.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
Instead of allocating a fixed amount of 128 bytes, which will overflow
and segfault, adjust the allocation to the length of the file name, and
if necessary trim the file name to make the prompt fit on the screen.
This fixes https://savannah.gnu.org/bugs/?47511.
Reported-by: Aapo Rantalainen <aapo.rantalainen@gmail.com>
Signed-off-by: Benno Schulenberg <bensberg@justemail.net>
the first element, and the insertion of a new element) directly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5678 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when the first Tab added the part that all matches have in common.
So now two Tabs in a row will always show the list of possible
completions -- if there /are/ any completions. Which means that
a second Tab will either: 1) do nothing, when the name is complete
and exists; 2) beep, when nothing in the current directory starts
with the current string; 3) show the list of matches.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5656 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
instead of in the given string. This fixes Savannah bug #47199.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5654 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes Savannah bug #47129 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5647 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
and also when it is the first and only line.
This fixes Savannah bug #47153 reported by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5646 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
needed), so that it no longer shows in the help screen nor in the file list.
This fixes Savannah bug #47126.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5640 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
With this option, nano would simply refuse to write to any symlinked file;
if anyone really used this option, they would certainly have complained.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5608 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
This fixes a segfault reported in Savannah bug #47011.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5596 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
(So that most likely not more than two hundred plus a handful
will be written out. This was the easiest to implement.)
See https://lists.gnu.org/archive/html/nano-devel/2016-01/msg00050.html.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5571 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
There's a bunch of return cases where we don't free the new full filename
which leads to leaks when writing out new files. One way to reproduce:
$ rm -f foo
$ nano foo
<hit enter>
<ctrl+o to save>
<ctrl+x to exit>
-> memory leak
Patch by Mike Frysinger.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5563 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
changed buffer after all, as the buffer may not have a name yet.
This fixes Savannah bug #46752.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5512 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
there's an error saving history state at exit is pointless and annoying.
Just notify the user and move on.
Patch by Mike Frysinger, tweaked and extended by Benno.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5507 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
not just for the first. This fixes Savannah bug #46511.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5500 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Users who want an immediate save, can bind the function 'savefile'.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5489 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
writing out the file immediately, without prompting.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5378 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
nor bothering with a separate initialization function when it's used only once.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5365 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
first asking for its name. Patch was suggested by Seiya Nuta.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5318 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
opening an empty buffer when the name of a directory is specified.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5304 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
before finding a unused filename takes an annoying amount of time.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5225 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
switch_to_prevnext_buffer() to support message passthrough
when trying to lock files using multibuffer.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5105 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (open_buffer): Check here for locking and properly
handle choosing to not open a file when locked instead of in
open_file(). Fixes Savannah bug 42373 reported by Benno Schulenberg
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5104 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (do_lockfile, open_file): If locking fails,
allow the lock failure message to be preserved AND
preserve the filename passed on the cmdline. Fixes
Savannah bug #42668.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5059 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
* src/files.c (do_lockfile): Check whether the directory
of the file we're trying to lock exists, and make the
resulting error message more intuitive. Fixes
Savannah bug 42639 by bens.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5056 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
having them declared everywhere and passing them around endlessly.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@5039 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
when --tempfile was given and the current buffer has no name.
This fixes Savannah bug #41750. Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4974 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
line numbers are long, x positions unsigned long.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4950 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
null_at(), adding a cast, and using an unsigned type for a length.
Patch by David Lawrence Ramsey.
git-svn-id: svn://svn.savannah.gnu.org/nano/trunk/nano@4939 35c25a1d-7b9e-4130-9fde-d3aeb78583b8
Benno Schulenberg