[RESOLU]script nautilus ne demarre pas (argument trop long)

Watael · Le 27/12/2024, à 16:50

oui, c'est ça. Mais comment accéder à ce dont parle Tawal ?

Tawal · Le 27/12/2024, à 17:02

Il me semble que c'est via nautilus-config-tool.

Frankkunst · Le 27/12/2024, à 17:20

Bonsoir à tous

iznobe a écrit :

c' est pour utiliser le script en mode graphique , en faisant un clic droit a partir de nautilus , sans avoir à ouvrir un terminal .
le script est alors lancé via nautilus , comme un addon ( personnalisé ) .

Comme je l'ai dit dans le premier poste mon script fonctionne parfaitement en console, mais j'aimerai en faire profiter ceux qui ne sont pas à l'aise face au terminal, comme ma fille .
Et donc avoir un outil à disposition dans le gestionnaire de fichier serait le top

Watael · Le 27/12/2024, à 18:21

Tawal a écrit :

Il me semble que c'est via nautilus-config-tool.

boh, j'ai pas ça, moi.
je ne le vois pas non plus dans les dépôts.
ça pourrait être une "extension" Gnome ?

Watael · Le 27/12/2024, à 18:24

Frankkunst a écrit :

Comme je l'ai dit dans le premier poste mon script fonctionne parfaitement en console

c'est bizarre. tu l'exécutes comment en ligne de commande ?
si les arguments sont les mêmes, alors la taille le nombre de caractères de la ligne de commande devrait être sensiblement le même, et ça devrait aussi échouer.

qui plus est, $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS n'est pas disponible en ligne de commande, alors comment afficherFichier() peut-elle fonctionner ?

Dernière modification par Watael (Le 27/12/2024, à 18:33)

Frankkunst · Le 27/12/2024, à 19:09

Bonsoir Watael,
Pour être clair, j'ai créé un premier script pour l'utiliser dans un terminal, quand j'étais dans un dossier de photo sous Nautilus , un clic droit entre des vignettes puis "ouvrir dans un terminal" .
J'étais dans le dossier et n'avais plus qu'à appeler mon script .
Et j'ai eu l'idée de pouvoir l'appeler directement depuis Nautilus, ayant lu sur la doc de script-nautilus que la sélection de fichier était stockée dans la variable "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS" ; j'ai donc modifié le script en conséquence !
Je crois que je vais passer le sujet en résolu, les extensions type "nautilus-actions-config-tool" "filemanager-actions" et "nautilus-extension-fma" ayant été supprimé des dépôts ... je ne vois pas comment modifier cette limitation ?!...
Déjà un grand merci à vous

Watael · Le 27/12/2024, à 19:37

ce n'est alors pas [résolu], mais [abandonné]

Frankkunst · Le 27/12/2024, à 19:55

Si tu veux, mais on a quand même réponse à la question !
Le problème vient d'une limitation interne à Nautilus ...
Je vois encore un peu ce qu'il est possible de faire
Bonne soirée

Watael · Hier à 01:18

une réponse, mais pas de solution, c'est toi qui voit, finalement.

mais je ne suis toujours pas convaincu qu'il s'agit d'une limitation de nautilus, puisque le message d'erreur concernant la longueur de la liste des arguments vient de /bin/sh

Tawal a écrit :

Par défaut, si [les propriétés min et max items] ne sont pas spécifiées, min_items est fixé à 1 et max_items est illimité.

s'il s'agissait d'une limitation de nautilus cette dernière limite serait évoquée.
je suppose.

Dernière modification par Watael (Hier à 01:31)

Watael · Hier à 01:51

démo:

# cat /tmp/test.sh 
#!/bin/bash
#
maFonc () 
{ 
    for f in "$@";
    do
        echo "$f";
    done
}
maFonc "$@"

# chmod +x /tmp/test.sh
# shopt -s globstar
# /tmp/test.sh /**
-bash: /tmp/test.sh: Liste d'arguments trop longue

je le fais en root parce que je n'ai pas assez de fichiers dans mon répertoire personnel.

Tawal · Hier à 06:33

Dans ta démo, peux-tu ajouter avant la boucle for :

lg="$*"
echo "nombres de caractères : ${#lg}"

Ceci afin de vérifier la longueur de la chaîne passée.
Mais possible aussi que l'erreur soit levée lors de l'interprétation de la ligne de commande.

Dernière modification par Tawal (Hier à 06:35)

Watael · Hier à 07:20

non, je ne peux pas.
enfin, si, je pourrais, mais le script n'est tout simplement pas exécuté.

l'erreur [est] levée lors de l'interprétation de la ligne de commande.

c'est ça.

notez que le problème, c'est le passage des arguments sur la ligne de commande, parce que cette version fonctionne :

#!/bin/bash
#
maFonc () 
{ 
    for f in "$@";
    do
        echo "$f";
    done
}

shopt -s globstar

maFonc /**

mais, ça ne résout pas le problème, parce qu'on ne peut pas récupérer la liste des fichiers sélectionnés dans Nautilus de cette façon.

Dernière modification par Watael (Hier à 07:21)

Frankkunst · Hier à 15:39

Bonjour,
Je suis tombé sur cette page blog-microsoft
il parle de 32 767 caractères, ce n'est pas le même environnement mais c'est une piste .
Pour ma part j'ai progressivement augmenté la taille de la variable en ajoutant au renommage 1 caractère supplémentaire au nom de fichier dans un dossier contenant 1505 fichiers.
il en ressort ceci :

frank@frank-ZenBook:~$ wc -m ~/Bureau/ResultatWatael.txt
138460 /home/frank/Bureau/ResultatWatael.txt
frank@frank-ZenBook:

La taille maximale avant que le script ne se lance plus .
On peut donc en déduire que la limite se situe entre 138460 et 139965 caractères
je vais encore essayer d'affiner ce nombre

Watael · Hier à 16:08

en effet, c'est un autre environnement, mais c'est surtout autre chose : ils parlent de la taille d'une variable d'environnement (telle que $HOME, par exemple, sur Linux, qui semble ne pas la définir); ce n'est pas la même chose que la longueur de la ligne de commande.

Frankkunst · Hier à 16:35

J'ai trouvé ceci :

frank@frank-ZenBook:~$ getconf -a | grep ARG_MAX
ARG_MAX                            2097152
_POSIX_ARG_MAX                     2097152
frank@frank-ZenBook:~$

et

frank@frank-ZenBook:~$ true | xargs --show-limits
Vos variables d'environnement occupent 2918 octets
Limite supérieure POSIX de longueur d'argument (sur ce système) : 2092186
Plus petite limite haute POSIX de longueur d'argument autorisée (tous systèmes) : 4096
Longueur maximale de la commande qui pourrait être utilisée : 2089268
Taille du tampon de commande actuellement utilisé : 131072
Parallélisation maximum (--max-procs ne peut pas être plus grand): 2147483647

frank@frank-ZenBook:~$

d'après cet article Ici

Frankkunst · Hier à 16:59

Voici la suite :

frank@frank-ZenBook:~$ maxvar.sh
sam. 28 déc. 2024 16:48:28 CET      1B
sam. 28 déc. 2024 16:48:28 CET      2B
sam. 28 déc. 2024 16:48:28 CET      4B
sam. 28 déc. 2024 16:48:28 CET      8B
sam. 28 déc. 2024 16:48:28 CET     16B
sam. 28 déc. 2024 16:48:28 CET     32B
sam. 28 déc. 2024 16:48:28 CET     64B
sam. 28 déc. 2024 16:48:28 CET    128B
sam. 28 déc. 2024 16:48:28 CET    256B
sam. 28 déc. 2024 16:48:28 CET    512B
sam. 28 déc. 2024 16:48:28 CET  1,0KiB
sam. 28 déc. 2024 16:48:28 CET  2,0KiB
sam. 28 déc. 2024 16:48:28 CET  4,0KiB
sam. 28 déc. 2024 16:48:28 CET  8,0KiB
sam. 28 déc. 2024 16:48:28 CET   16KiB
sam. 28 déc. 2024 16:48:28 CET   32KiB
sam. 28 déc. 2024 16:48:28 CET   64KiB
sam. 28 déc. 2024 16:48:28 CET  128KiB
sam. 28 déc. 2024 16:48:29 CET  256KiB
sam. 28 déc. 2024 16:48:29 CET  512KiB
sam. 28 déc. 2024 16:48:29 CET  1,0MiB
sam. 28 déc. 2024 16:48:29 CET  2,0MiB
sam. 28 déc. 2024 16:48:29 CET  4,0MiB
sam. 28 déc. 2024 16:48:29 CET  8,0MiB
sam. 28 déc. 2024 16:48:29 CET   16MiB
sam. 28 déc. 2024 16:48:29 CET   32MiB
sam. 28 déc. 2024 16:48:30 CET   64MiB
sam. 28 déc. 2024 16:48:31 CET  128MiB
sam. 28 déc. 2024 16:48:34 CET  256MiB
sam. 28 déc. 2024 16:48:39 CET  512MiB
sam. 28 déc. 2024 16:48:50 CET  1,0GiB
/home/frank/bin/maxvar.sh: xrealloc : impossible d'allouer 18446744071562068096 octets
frank@frank-ZenBook:~$

et

frank@frank-ZenBook:~$ maxvarfin.sh
sam. 28 déc. 2024 16:52:51 CET      0B
sam. 28 déc. 2024 16:53:10 CET  600MiB
sam. 28 déc. 2024 16:53:33 CET  700MiB
sam. 28 déc. 2024 16:54:00 CET  800MiB
sam. 28 déc. 2024 16:54:28 CET  900MiB
frank@frank-ZenBook:~$

Tawal · Hier à 17:13

On a aussi ulimit (primitive du shell).
On peut connaître et augmenter la taille de la pile.

$ # On consulte la valeur
$ ulimit -s
8192
$ # Elle est donnée en KiB
$ echo $((8192*1024/4))
2097152
$
$ # On double la valeur
$ ulimit -s 16384
$ ulimit -s
16384
$

À essayer dans le .bashrc …

Edit:
Ça devrait fonctionner.
J'ai testé ceci dans un terminal :
(une fois la limite atteinte ou la pile utilisée [je ne sais pas], il faut changer de shell pour pouvoir changer la taille)

$ cat t
#!/bin/bash

args="$*"
echo ${#args}
$ 
$ bash
$ # On est dans un sous-shell
$
$ ./t /home/tawal/Term/**
bash: ./t: Liste d'arguments trop longue
$
$ ulimit -s 16384
bash: ulimit: stack size : impossible de modifier la limite : Opération non permise
$ exit
exit
$ # On a quitté le sous-shell
$
$ ulimit -s 16384
$ ./t /home/tawal/Term/**
3256862
$

Edit2:
Il faut comprendre qu'augmenter la valeur de la pile réserve d'autant de la RAM.
Une valeur de 16384 correspond à 16Mo de RAM réservée rien que pour la ligne de commande.

Dernière modification par Tawal (Hier à 18:19)

Watael · Hier à 18:32

~/.bashrc ne sera pas lu lors de l'exécution d'un script.

Frankkunst · Hier à 19:39

J'ai modifié le fichier /etc/security/limits.conf, selon cette page ici, comme suit :

# /etc/security/limits.conf
#
#Each line describes a limit for a user in the form:
#
#<domain>        <type>  <item>  <value>
#
#Where:
#<domain> can be:
#        - a user name
#        - a group name, with @group syntax
#        - the wildcard *, for default entry
#        - the wildcard %, can be also used with %group syntax,
#                 for maxlogin limit
#        - NOTE: group and wildcard limits are not applied to root.
#          To apply a limit to the root user, <domain> must be
#          the literal username root.
#
#<type> can have the two values:
#        - "soft" for enforcing the soft limits
#        - "hard" for enforcing hard limits
#
#<item> can be one of the following:
#        - core - limits the core file size (KB)
#        - data - max data size (KB)
#        - fsize - maximum filesize (KB)
#        - memlock - max locked-in-memory address space (KB)
#        - nofile - max number of open file descriptors
#        - rss - max resident set size (KB)
#        - stack - max stack size (KB)
#        - cpu - max CPU time (MIN)
#        - nproc - max number of processes
#        - as - address space limit (KB)
#        - maxlogins - max number of logins for this user
#        - maxsyslogins - max number of logins on the system
#        - priority - the priority to run user process with
#        - locks - max number of file locks the user can hold
#        - sigpending - max number of pending signals
#        - msgqueue - max memory used by POSIX message queues (bytes)
#        - nice - max nice priority allowed to raise to values: [-20, 19]
#        - rtprio - max realtime priority
#        - chroot - change root to directory (Debian-specific)
#
#<domain>      <type>  <item>         <value>
#

#*               soft    core            0
#root            hard    core            100000
#*               hard    rss             10000
#@student        hard    nproc           20
#@faculty        soft    nproc           20
#@faculty        hard    nproc           50
#ftp             hard    nproc           0
#ftp             -       chroot          /ftp
#@student        -       maxlogins       4

# End of file
root       soft    msgqueue        unlimited
root       hard    msgqueue        unlimited
frank       soft    msgqueue        unlimited
frank       hard    msgqueue        unlimited

Mais rien n'y fait
j'ai pourtant maintenant :

frank@frank-ZenBook:~$ ulimit -q
unlimited

et

frank@frank-ZenBook:~$ cat /proc/sys/fs/mqueue/msg_max
10000

Toujours le même problème ?!!!

Dernière modification par Frankkunst (Hier à 19:42)

Tawal · Hier à 21:24

Un truc me tracasse.
La liste des fichiers sélectionnés n'est pas passée au script en tant qu'arguments.
Mais elle est via une variable (exportée ? sûrement) NAUTILUS_SCRIPT_SELECTED_FILE_PATHS
Or l'affectation d'une variable n'est pas soumise à cette limitation.
Il devrait être possible d'accéder aux éléments de cette liste ainsi :

for f in $NAUTILUS_SCRIPT_SELECTED_FILE_PATHS;
do
...

Edit:
Je ne sais pas comment sont gérés les espaces dans les noms de fichier.
Alors, je proposerais plutôt ceci :

readarray -t Args <<< "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS"
for f in "${Args[@]}"
do
   # Traitement
done

Dernière modification par Tawal (Hier à 21:33)

Frankkunst · Aujourd'hui à 10:32

Bonjour Tawal
Toujours le même comportement avec :

#!/bin/bash
#
readarray -t Args <<< "$NAUTILUS_SCRIPT_SELECTED_FILE_PATHS"
for f in "${Args[@]}"
do
    if test "$(file --brief --mime-type "$f")" = 'image/jpeg'
    then
        printf "$f\n" >>~/Bureau/ResultatWatael.txt
    fi
done

!...

Frankkunst · Aujourd'hui à 10:43

j'ai trouvé ici, une solution avec xargs, mais le problème est qu'il faudrait le placer avant l'appel du script ...
Et dans le cas présent si j'ai bien compris le scrippt est appelé par Nautilus

iznobe · Aujourd'hui à 10:50

Bonjour , question bete qui n' a pas encore été evoquée , mais ca ne serait pas plus simple de changer de gestionnaire de fichiers .
Peut etre que tous n' ont pas cette " limite " ?

Nemo est un fork de nautilus a la base ( me semble t il ) , donc plutot à eviter pour ce retrouver avec la meme limite . Cela dit il en existe plein d' autres .

Dernière modification par iznobe (Aujourd'hui à 10:51)

Watael · Aujourd'hui à 11:22

la limite n'est pas due au gestionnaire de fichiers (stfw "argument list too long"), mais à la configuration du noyau linux qui limite la longueur de la ligne de commande.

iznobe · Aujourd'hui à 11:26

ha bon , pourquoi donc le soucis n' apprait que lors de l 'utilisation du script en passant par nautilus alors ?

j ' ai pas tout compris ...

Dernière modification par iznobe (Aujourd'hui à 11:27)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 27/12/2024, à 16:50

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#27 Le 27/12/2024, à 17:02

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#28 Le 27/12/2024, à 17:20

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#29 Le 27/12/2024, à 18:21

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#30 Le 27/12/2024, à 18:24

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#31 Le 27/12/2024, à 19:09

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#32 Le 27/12/2024, à 19:37

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#33 Le 27/12/2024, à 19:55

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#34 Hier à 01:18

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#35 Hier à 01:51

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#36 Hier à 06:33

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#37 Hier à 07:20

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#38 Hier à 15:39

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#39 Hier à 16:08

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#40 Hier à 16:35

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#41 Hier à 16:59

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#42 Hier à 17:13

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#43 Hier à 18:32

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#44 Hier à 19:39

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#45 Hier à 21:24

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#46 Aujourd'hui à 10:32

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#47 Aujourd'hui à 10:43

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#48 Aujourd'hui à 10:50

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#49 Aujourd'hui à 11:22

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

#50 Aujourd'hui à 11:26

Re : [RESOLU]script nautilus ne demarre pas (argument trop long)

Pied de page des forums