Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1271084 > unrolled thread

Bug#1121061: libreoffice: undocumented limit of 249 arguments

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#1121061: libreoffice: undocumented limit of 249 arguments Rene Engelhard <rene@debian.org> - 2025-11-21 21:20 +0100
    Bug#1121061: libreoffice: undocumented limit of 249 arguments Rene Engelhard <rene@debian.org> - 2025-11-21 21:30 +0100
    Bug#1121061: libreoffice: undocumented limit of 249 arguments Francesco Potortì <Potorti@isti.cnr.it> - 2025-11-22 02:20 +0100
      Bug#1121061: libreoffice: undocumented limit of 249 arguments Rene Engelhard <rene@debian.org> - 2025-11-22 04:20 +0100
        Bug#1121061: libreoffice: undocumented limit of 249 arguments Francesco Potortì <Potorti@isti.cnr.it> - 2025-11-22 23:30 +0100
      Bug#1121061: libreoffice: undocumented limit of 249 arguments Rene Engelhard <rene@debian.org> - 2025-11-22 12:50 +0100

#1271084 — Bug#1121061: libreoffice: undocumented limit of 249 arguments

tag 1121061 + moreinfo

thanks


Hi,

Am 20.11.25 um 13:20 schrieb Francesco Potortì:
> Package: libreoffice
> Version: 4:25.8.2-3
> Severity: normal
>
> When libreoffice is called from the command line for batch processing with --convert-to it apparently forces a limit on the number of arguments without telling.
>
> In my case, when giving the names of 371 files on the command line, it starts working and printing two lines for each processed file until 249 files are processed, then it hangs.
>
> If I give it 249 file arguments, it works without problems.  The command line is:
>
> /usr/lib/libreoffice/program/oosplash --convert-to csv:Text - txt - csv (StarCalc):44,,,,,,,,,,,3 --outdir ./tmp.GYzB1YV6z1 [ 42-char file names]

http://google.com/search?q=libreoffice+argument+limit+convert-to:

"

There is no specific argument limit for the libreoffice --convert-to command itself, but shell limitations on the number of arguments can cause issues when converting a very large number of files at once. To overcome this, process files in batches by creating scripts that convert groups of files, or use a tool like xargs to handle the conversion and avoid exceeding the shell's argument list limits, explains Stack Overflow. 
Batch processing: Write a script to convert files in smaller, manageable batches to stay under the shell's argument limit.
xargs: Use the xargs command, which is designed to build and execute command lines from standard input, to avoid hitting the argument count limit.
xargs example: find . -name "*.docx" -print0 | xargs -0 libreoffice --convert-to pdf

"

(AI, but..)


Sounds like your case exactly?


And if it's the shell limit,  there's nothing LO can do. Neither should it.

Regadrs,


Rene

[toc] | [next] | [standalone]

#1271085

Hi,

Am 21.11.25 um 21:14 schrieb Rene Engelhard:
> And if it's the shell limit,  there's nothing LO can do. Neither should it.

FWIW, It's the same as if you would rm * and get a "argument limit too long". See e.g.
https://stackoverflow.com/questions/11289551/argument-list-too-long-error-for-rm-cp-mv-commands

I can buy that essential tools like cp, mv etc might want to report this, but giving this much to LibreOffice probably just
fails into the "don't do that" category. (Or make it minor, since it's just not documenting something which everyone
should know anyway.)

Regards,
  
Rene

[toc] | [prev] | [next] | [standalone]

#1271109

>> Package: libreoffice
>> Version: 4:25.8.2-3
>> Severity: normal
>>
>> When libreoffice is called from the command line for batch processing with --convert-to it apparently forces a limit on the number of arguments without telling.
>>
>> In my case, when giving the names of 371 files on the command line, it starts working and printing two lines for each processed file until 249 files are processed, then it hangs.
>>
>> If I give it 249 file arguments, it works without problems.  The command line is:
>>
>> /usr/lib/libreoffice/program/oosplash --convert-to csv:Text - txt - csv (StarCalc):44,,,,,,,,,,,3 --outdir ./tmp.GYzB1YV6z1 [ 42-char file names]
>
>http://google.com/search?q=libreoffice+argument+limit+convert-to:
>
>"
>There is no specific argument limit for the libreoffice --convert-to command itself
...
>(AI, but..)

I investigated a bit, and that's what I found.

Bash does not have a limit on line length or number of arguments.  The operating system has a line length limit, and on my Linux box it is

$ getconf ARG_MAX
2505728

In the case I reported, the line length was about 43*371+123=16076.  Just for double check, ls on my entire directory takes 718 arguments without a problem:

$ ls -1 * | wc -l
719

which is what one expects from the Gnu core utils.

However /usr/lib/libreoffice/program/soffice has a limit of of 254 arguments (including the process file name), and the reason is that it is a shell script starting with !/bin/sh, which on my system means that dash is called.  Experiments show that the limit on numer of arguments is imposed by Dash.  In fact, if one calls /usr/lib/libreoffice/program/oosplash rather than /usr/lib/libreoffice/program/soffice then the limit disappears.

I suggest that the shell scripts under /usr/lib/libreoffice/program use Bash rather than Dash, and that the libreoffice-common package is made to depend on the bash package.

This is not a significant lack of efficiency, as the overhead of launching bash is negligible with respect to launching soffice from any point of view: cpu time, memory size, disk space occupied.

-- 
Francesco Potortì (ricercatore)        Mobile: +39.348.8283.107	     
ISTI - Area della ricerca CNR          Teams:  wnlabisti	     
via G. Moruzzi 1, I-56124 Pisa         Web:    http://fly.isti.cnr.it
(gate 20, 1st floor, room C71)         ISPIN:  https://ieee-jispin.org/

[toc] | [prev] | [next] | [standalone]

#1271115

tag 1121061 - moreinfo

tag 112106 - unreproducible

severity 112106 minor

thanks


Hi,

Am 22.11.25 um 02:06 schrieb Francesco Potortì:
>>> Package: libreoffice
>>> Version: 4:25.8.2-3
>>> Severity: normal
>>>
>>> When libreoffice is called from the command line for batch processing with --convert-to it apparently forces a limit on the number of arguments without telling.
>>>
>>> In my case, when giving the names of 371 files on the command line, it starts working and printing two lines for each processed file until 249 files are processed, then it hangs.
>>>
>>> If I give it 249 file arguments, it works without problems.  The command line is:
>>>
>>> /usr/lib/libreoffice/program/oosplash --convert-to csv:Text - txt - csv (StarCalc):44,,,,,,,,,,,3 --outdir ./tmp.GYzB1YV6z1 [ 42-char file names]
>> http://google.com/search?q=libreoffice+argument+limit+convert-to:
>>
>> "
>> There is no specific argument limit for the libreoffice --convert-to command itself
> ...
>> (AI, but..)
> I investigated a bit, and that's what I found.
>
> Bash does not have a limit on line length or number of arguments.  The operating system has a line length limit, and on my Linux box it is
>
> $ getconf ARG_MAX
> 2505728

Yeah, that was my initial idea, but 10500 as for 49 files is much lower than that, indeed.

> In the case I reported, the line length was about 43*371+123=16076.  Just for double check, ls on my entire directory takes 718 arguments without a problem:
>
> $ ls -1 * | wc -l
> 719
I see.
> which is what one expects from the Gnu core utils.

I actually would be surprised if the GNU core utils (e.g. rm) worked with rm'ing 59660 files. And inded it doesn't, but gets surprsingly (to me) close:

rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000010000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
10000
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000020000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
20000
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 000000000000000000000000000000000000000000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
ls: cannot access '0*': No such file or directory

0
rm: cannot remove '*': No such file or directory
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 000000000000000000000000000000000000000000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
ls: cannot access '0*': No such file or directory

0
rm: cannot remove '*': No such file or directory
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000030000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
30000
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000040000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
40000
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000050000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
bash: /usr/bin/ls: Argument list too long

0
bash: /usr/bin/rm: Argument list too long

So there is also another limit here, somewhere between 40000 and 41000?:

rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000040000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
40000
rene@frodo:~/test$ echo -n "000000000000000000000000000000000000000001" | wc -c && for i in `seq -w 0000000000000000000000000000000000000000001 0000000000000000000000000000000000000041000`; do echo $i > $i; done && ls -1 0* | wc -l; rm *
42
bash: /usr/bin/ls: Argument list too long

0
bash: /usr/bin/rm: Argument list too long

> However /usr/lib/libreoffice/program/soffice has a limit of of 254 arguments (including the process file name), and the reason is that it is a shell script starting with !/bin/sh, which on my system means that dash is called.  Experiments show that the limit on numer of arguments is imposed by Dash.  In fact, if one calls /usr/lib/libreoffice/program/oosplash rather than /usr/lib/libreoffice/program/soffice then the limit disappears.
>
> I suggest that the shell scripts under /usr/lib/libreoffice/program use Bash rather than Dash,

But then we just exchange a limit to another one.. Which is much bigger, admittedly, though :)


> and that the libreoffice-common package is made to depend on the bash package.
bash actually is still pseudo-essential I think
> This is not a significant lack of efficiency, as the overhead of launching bash is negligible with respect to launching soffice from any point of view: cpu time, memory size, disk space occupied.

Yes, but why not feed 249 (or 251) files each run if one knew (as you do now) about the limit?


And LibreOffice is not special here, there's a s*load of !#/bin/sh scripts in Debian. You ae not seriously suggesting to change all of them to bash for this reason if they handled files?

There is a reason Debian choose dash for /bin/sh, which *was* efficiency for #!/bin/sh scripts.


Regards,


Rene

[toc] | [prev] | [next] | [standalone]

#1271234

>I actually would be surprised if the GNU core utils (e.g. rm) worked with rm'ing 59660 files.

>bash: /usr/bin/ls: Argument list too long
>bash: /usr/bin/rm: Argument list too long

These limits are not on the core utils (rm  or ls) but on the exec system call line length.  ls and rm have no limits on their own: since they were born, the Gnu utils have been free of arbitrary limits.

>> I suggest that the shell scripts under /usr/lib/libreoffice/program use Bash rather than Dash,

>But then we just exchange a limit to another one.. Which is much bigger, admittedly, though :)

Sure, but the second one is the limit imposed by the kernel, that is, the same line length limit that all processes have when calling exec(2).  Not an unexpected unexplicable much lower limit.

More important yet, when the length of the command line exceeds ARG_MAX, rm and ls emit a warning and exit with error, while when the number of arguments in libreoffice exceeds 251 no warning is given.
 
>> and that the libreoffice-common package is made to depend on the bash package.
>bash actually is still pseudo-essential I think

Hm, do not know.

>> This is not a significant lack of efficiency, as the overhead of launching bash is negligible with respect to launching soffice from any point of view: cpu time, memory size, disk space occupied.
>
>Yes, but why not feed 249 (or 251) files each run if one knew (as you do now) about the limit?

That's what I am doing in my script now.

But once you find a bug and a way to get around it, that is still a bug, and can hit other people.  That's the very reason to signal and correct bugs that can be worked around.  It took me some hours to understand why my script did not work.

>And LibreOffice is not special here, there's a s*load of !#/bin/sh scripts in Debian. You ae not seriously suggesting to change all of them to bash for this reason if they handled files?

>There is a reason Debian choose dash for /bin/sh, which *was* efficiency for #!/bin/sh scripts.

The move from bash to dash is relatively recent in Debian.  Most of those scripts were written at a time when this problem did not exist.  And the reason of switching to dash was for efficiency of system scripts, as far as I know.  Efficiency is not relevant for user-level interactive scripts so yes, this is probably a wider problem: using !# /bin/sh makes sense for system-level scripts, but not otherwise, especially when that introduces an artificial limit on the number of arguments.

Anyway, I suggest to investigate dash's behaviour and ensure that my diagnosis is correct, because the existence of such a limit looks strange to me. If it is confirmed, file a bug with dash and change /bin/sh into /bin/bash in libreoffice's scripts.

[toc] | [prev] | [next] | [standalone]

#1271155

Hi,

Am 22.11.25 um 02:06 schrieb Francesco Potortì:
> I suggest that the shell scripts under /usr/lib/libreoffice/program use Bash rather than Dash,

So basically something along

 From 58e2efd7fd734ee042872de3480d1c767610db6f Mon Sep 17 00:00:00 2001
From: Rene Engelhard <rene@rene-engelhard.de>
Date: Sat, 22 Nov 2025 12:42:13 +0100
Subject: [PATCH] use /bin/bash instead of /bin/sh in wrapper scripts (except
  for unopkg and the SDK for now) (closes: #1121061)

---
  changelog                            | 10 ++++
  patches/series                       |  1 +
  patches/shell-wrappers-use-bash.diff | 83 ++++++++++++++++++++++++++++
  3 files changed, 94 insertions(+)
  create mode 100644 patches/shell-wrappers-use-bash.diff

diff --git a/changelog b/changelog
index 4adfa0ec0..3f3ba8f63 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,13 @@
+libreoffice (4:26.2.0~beta1~git20251122-1) UNRELEASED; urgency=medium
+
+  * New upstream snapshot
+
+  * debian/patches/shell-wrappers-use-bash.diff: use /bin/bash instead of
+    /bin/sh in wrapper scripts (except for unopkg and the SDK for now)
+    (closes: #1121061)
+
+ -- Rene Engelhard <rene@debian.org>  Fri, 21 Nov 2025 21:07:00 +0100
+
  libreoffice (4:26.2.0~alpha1-1) experimental; urgency=medium

    * New upstream alpha release
diff --git a/patches/series b/patches/series
index 5aeb6d996..5469fdabf 100644
--- a/patches/series
+++ b/patches/series
@@ -51,3 +51,4 @@ cargo-build-flag.diff
  #strict-firebird-api-version-check.diff
  fix-rust_uno-test.diff
  revert-2b322af4b9473210ed6a332115dac381f07039d6.diff
+shell-wrappers-use-bash.diff
diff --git a/patches/shell-wrappers-use-bash.diff b/patches/shell-wrappers-use-bash.diff
new file mode 100644
index 000000000..d1d4ad095
--- /dev/null
+++ b/patches/shell-wrappers-use-bash.diff
@@ -0,0 +1,83 @@
+diff --git a/desktop/scripts/sbase.sh b/desktop/scripts/sbase.sh
+index 82e5e4ba2bb9..1c1a410b5a0d 100755
+--- a/desktop/scripts/sbase.sh
++++ b/desktop/scripts/sbase.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+
+ cmd=$(dirname "$0")/soffice
+ exec "$cmd" --base "$@"
+diff --git a/desktop/scripts/scalc.sh b/desktop/scripts/scalc.sh
+index ff3d597951a4..2a1b0833948f 100755
+--- a/desktop/scripts/scalc.sh
++++ b/desktop/scripts/scalc.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+
+ cmd=$(dirname "$0")/soffice
+ exec "$cmd" --calc "$@"
+diff --git a/desktop/scripts/sdraw.sh b/desktop/scripts/sdraw.sh
+index 9f7c1e4eda99..8c19828e10a1 100755
+--- a/desktop/scripts/sdraw.sh
++++ b/desktop/scripts/sdraw.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+
+ cmd=$(dirname "$0")/soffice
+ exec "$cmd" --draw "$@"
+diff --git a/desktop/scripts/simpress.sh b/desktop/scripts/simpress.sh
+index a1808c3cb1f7..9a7c4a3448a3 100755
+--- a/desktop/scripts/simpress.sh
++++ b/desktop/scripts/simpress.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+
+ cmd=$(dirname "$0")/soffice
+ exec "$cmd" --impress "$@"
+diff --git a/desktop/scripts/smath.sh b/desktop/scripts/smath.sh
+index 9c05223b454f..8e986465646d 100755
+--- a/desktop/scripts/smath.sh
++++ b/desktop/scripts/smath.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+
+ cmd=$(dirname "$0")/soffice
+ exec "$cmd" --math "$@"
+diff --git a/desktop/scripts/soffice.sh b/desktop/scripts/soffice.sh
+index 7188f393e140..bcfe77bbe1d2 100755
+--- a/desktop/scripts/soffice.sh
++++ b/desktop/scripts/soffice.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+ #
+ # This file is part of the LibreOffice project.
+ #
+diff --git a/desktop/scripts/swriter.sh b/desktop/scripts/swriter.sh
+index 19a7c9ed4191..41bf3693abce 100755
+--- a/desktop/scripts/swriter.sh
++++ b/desktop/scripts/swriter.sh
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+
+ cmd=$(dirname "$0")/soffice
+ exec "$cmd" --writer "$@"
+diff --git a/bin/distro-install-desktop-integration b/bin/distro-install-desktop-integration
+index 7e1428ffba69..0022fdb2e7e2 100755
+--- a/bin/distro-install-desktop-integration
++++ b/bin/distro-install-desktop-integration
+@@ -27,7 +27,7 @@ create_wrapper()
+     else
+         mkdir -p "$DESTDIR$BINDIR"
+         cat <<EOT >"$DESTDIR$BINDIR/$1"
+-#!/bin/sh
++#!/bin/bash
+ $INSTALLDIR/program/$2 $3 "\$@"
+ EOT
+         chmod 755 "$DESTDIR$BINDIR/$1"
-- 
2.47.3


(diff'ed on top of 26.2 tree)


Still not decided whether we actually should do that...


Regards,


Rene

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web