Package: octave
Version: 9.4.0-1
Severity: normal

octave> unlink nonexistent_file
error: unlink: operation failed: No such file or directory

An old script of mine fails because of this. Once upon a time Octave did not raise an error upno failure of unlink. This should be documented

-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (990, 'testing'), (101, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.12.11-amd64 (SMP w/24 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages octave depends on:
ii libamd3 1:7.10.1+dfsg-1
ii libarpack2t64 3.9.1-6
ii libatlas3-base [liblapack.so.3] 3.10.3-14
ii libblas3 [libblas.so.3] 3.12.1-2
ii libbz2-1.0 1.0.8-6
ii libc6 2.41-7
ii libccolamd3 1:7.10.1+dfsg-1
ii libcholmod5 1:7.10.1+dfsg-1
ii libcolamd3 1:7.10.1+dfsg-1
ii libcurl3t64-gnutls 8.13.0-1
ii libcxsparse4 1:7.10.1+dfsg-1
ii libfftw3-double3 3.3.10-2+b1
ii libfftw3-single3 3.3.10-2+b1
ii libfltk-gl1.3t64 1.3.11-1
ii libfltk1.3t64 1.3.11-1
ii libfontconfig1 2.15.0-2.3
ii libfreetype6 2.13.3+dfsg-1
ii libgcc-s1 14.2.0-19
ii libgfortran5 14.2.0-19
ii libgl1 1.7.0-1+b2
ii libgl2ps1.4 1.4.2+dfsg1-2
ii libglpk40 5.0-1+b2
ii libglu1-mesa [libglu1] 9.0.2-1.1+b3
ii libgomp1 14.2.0-19
ii libgraphicsmagick++-q16-12t64 1.4+really1.3.45+hg17696-1
ii libgraphicsmagick-q16-3t64 1.4+really1.3.45+hg17696-1
ii libhdf5-310 1.14.5+repack-3
ii liblapack3 [liblapack.so.3] 3.12.1-2
ii libopenblas0-pthread [liblapack.so.3] 0.3.29+ds-3
ii libpcre2-8-0 10.45-1
ii libportaudio2 19.6.0-1.2+b3
ii libqhull-r8.0 2020.2-6+b2
ii libqrupdate1 1.1.5-1
ii libqscintilla2-qt6-15 2.14.1+dfsg-1+b4
ii libqt6core5compat6 6.8.2-3+b1
ii libqt6core6t64 6.8.2+dfsg-5+b1
ii libqt6gui6 6.8.2+dfsg-5+b1
ii libqt6help6 6.8.2-4
ii libqt6network6 6.8.2+dfsg-5+b1
ii libqt6opengl6 6.8.2+dfsg-5+b1
ii libqt6openglwidgets6 6.8.2+dfsg-5+b1
ii libqt6printsupport6 6.8.2+dfsg-5+b1
ii libqt6widgets6 6.8.2+dfsg-5+b1
ii libqt6xml6 6.8.2+dfsg-5+b1
ii libreadline8t64 8.2-6
ii libsndfile1 1.2.2-2+b1
ii libspqr4 1:7.10.1+dfsg-1
ii libstdc++6 14.2.0-19
ii libsuitesparseconfig7 1:7.10.1+dfsg-1
ii libumfpack6 1:7.10.1+dfsg-1
ii libx11-6 2:1.8.12-1
ii octave-common 9.4.0-1
ii texinfo 7.1.1-1
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1

Versions of packages octave recommends:
ii default-jre-headless 2:1.21-76
ii epstool 3.09-4
ii gnuplot-qt [gnuplot-x11] 6.0.2+dfsg1-1
ii libopenblas0 0.3.29+ds-3
ii octave-doc 9.4.0-1
ii pstoedit 4.02-1+b1

Versions of packages octave suggests:
pn octave-dev <none>

-- no debconf information

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Control: reopen -1
Control: tags -1 + upstream
Control: forwarded -1 https://savannah.gnu.org/bugs/index.php?67043

* Francesco Potortì <Potorti@isti.cnr.it> [2025-04-22 18:06]:

The behavior of unlink and many other functions has been changed in
version 7.0 of Octave. This is well documented. Here is an excerpt of
the file etc/NEWS.7.md:

There are two documentation issues here. First, this is not what the manual says:

-- : unlink (FILE)
-- : [STATUS, MSG] = unlink (FILE)
Delete the file named FILE.

If successful, STATUS is 0 and MSG is an empty string. Otherwise,
STATUS is -1 and MSG contains a system-dependent error message.

See also: *note delete: XREFdelete, *note rmdir: XREFrmdir.

As you can see, nowhere is it mentioned that unlink may throw an error
when called without a return value.

Fair enough. I am hereby reopening this bug report. Indeed, the
help documentation is incomplete.

Moreover, the NEWS file that you cited mentions a difference in command
form versus functional form, but that is not the issue. In fact, my
old program uses a functional form, and yet:

octave> unlink("nonexistent_file")
error: unlink: operation failed: No such file or directory

So both the manual and the NEWS file need to be corrected and should
state that unlink (and others) may throw an error unless they are
called with at least one return value.

Indeed, the documentation in NEWS.7.md is not perfect. It assumes
that when using the functional form, the user *always* collect the
status in an output variable.

I forwarded this bug report upstream.

Thanks,

Rafael Laboissière

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)