Re: meilleure maniere de prendre en compte les arguments dans un script ksh

Auteur: <openbsd.fr.eu.sy_at_puu.re>
Date: Mon, 30 Mar 2020 23:16:45 +0200

On 30.03.2020 10:54, prx wrote:
> * openbsd.fr.eu.sy_at_puu.re <openbsd.fr.eu.sy_at_puu.re> le [26-03-2020
> 16:23:33 +0100]:
>> Le truc c'est que les echappements, les quotes ou double quotes ne
>> passent
>> pas.
>>
>>
>> Pour donner une idée, le script est actuellement accessible ici:
>> https://sy.puu.re/flo
>>
>> Concernant le briefing sur le script, celui-ci est inspiré de srss
>> pour
>> envoyer par mail les elements des flux rss (une reprise de la version
>> golang
>> qui ne me satisfaisait pas, 10mo a cause du runtime pour la tache,
>> c'est
>> trop gros ^^).
>> De base, il envoie les mails en html mais il a la possibilité de les
>> envoyer
>> en text ou multi text&html si on y rajoute en parametre la commande
>> pour
>> traduire le html en text.
>> Cela permet d'utiliser py-html2text, pandoc ou autre selon les
>> desideratas
>> de l'utilisateur pour la conversion en texte.
>>
>> Le probleme est que ces derniers peuvent recevoir des arguments. Ainsi
>> on
>> peut convertir via pandoc par exemple avec "pandoc -r html -t
>> markdown_mmd"
>> ou "pandoc -r html -t gfm" selon le rendu voulu.
>>
>> Voila des exemples d'usage avec commandes (avec le script tel
>> qu'actuellement getopt le permet):
>> flo -f both -o pandoc/-f/html/-t/markdown_mmd
>> flo -f text -o html2text/-nobs
>>
>> Et voici l'usage qui aurait été préféré:
>> flo -f both -o "pandoc -f html -t markdown_mmd"
>> flo -f text -o "html2text -nobs"
>>
>>
>> La liste des liens de flux doit se trouver dans le fichier
>> ~/.config/flo/flows, un par ligne.
>>
>> On 26.03.2020 14:59, prx wrote:
>> > * openbsd.fr.eu.sy_at_puu.re <openbsd.fr.eu.sy_at_puu.re> le [26-03-2020
>> > 10:35:37 +0100]:
>> > > Bonjour à tous,
>> > >
>> > > Je profite d'un essai au scriptage avec ksh pour émettre mon premier
>> > > vrai
>> > > message public (en dehors de celui de présentation) à la communauté
>> > > francophone OpenBSD.
>> > >
>> > > Je souhaite intégrer la prise en compte d'arguments à un script.
>> > > Il y a dans le système de base la commande 'getopt' qui permet cela
>> > > mais
>> > > elle a des problèmes à gérer les arguments comportant des espaces (
>> > > indiqué
>> > > même dans la page man ).
>> > >
>> > > Ainsi, il n'est pas possible avec de lancer un script tel que:
>> > > programme_script -d "argument avec espace"
>> > >
>> > > Pour l'instant je contourne le probleme en remplacant les espaces
>> > > par des
>> > > slashs. Ceci dit, ce petit hack ne me satisfait guère.
>> > >
>> > > J'en appelle à vous pour savoir si vous connaissez une meilleure
>> > > solution à
>> > > proposer.
>> > >
>> > > Merci,
>> > > Sÿ
>> >
>> > Salut,
>> > Je crois qu'échapper les espaces est la meilleure méthode.
>> > On peut voir un exemple de ton script (si ça peut donner une
>> > idée...)?
>>
>
>
> Vu ce que je lis, je vois 3 solutions éventuelles (c'est
> à dire pas testées):
>
> * Modifier l'IFS
> * Écrire une finction que va faire le boulot à la place de
> getopt. Ça ressemblerait à:
> args=""
> flag=""
> case i in $_at_
> -*)
> # do struff with args...
> args="" # reset arg
> flag=$i
> ;;
> *)
> args="$args $i"
> ;;
> esac
> C'est loin d'être idéal...
> * Ne pas utiliser d'espaces. Pourquoi pas faire appel à un script
> qui contiendrai la commande "pandoc ..." ?

Merci de la reponse.

- Faire appel a un script, j'y avais pensé mais c'est loin d'etre ideal
non plus.

- Modifier l'IFS, ca reviendrai un peu au meme que de selectionner un
autre separateur comme la le slash non? car il faut toujours l'espace
comme separateur pour les autres arguments.

- La fonction qui fait le boulot me semble la meilleure pour avoir une
interface d'appel du programme qui me convienne et reste la meme malgré
les maj mais comme tu dis, ce n'est pas ideal non plus.. rajouter du
code.. a vrai dire, je pensais plus a en enlever.. quitte a laisser les
gens changer les parametres voulus dans le code directement comme le
promotionne Suckless.

Du coup ca me confirme qu'il n'y a pas de solution idéale préconisée
pour ce genre de cas. :/
ReÇu le Mon Mar 30 2020 - 23:16:45 CEST

Cette archive a été créée par hypermail 2.3.0 : Tue Mar 31 2020 - 00:00:01 CEST