Ubuntu-fr

# Pour chaque fichier commençant par un 't', on crée une variable nommée fic
for fic in t*; do
  # On supprime l'extension de fic pour générer le nom du répertoire dans une variable nommée rep
  rep="$(cut -d'.' -f1 <<< "$fic")"
  # On crée ce répertoire rep
  mkdir -p "$rep"
  # Et on déplace fic vers rep
  mv "$fic" "$rep"
# Fin de la boucle for
done

Pour plus de détail :

$ cut -d';' -f2 <<< "bla;bli;blu"
bli
$ cut -d';' -f3 <<< "bla;bli;blu"
blu
$ cut -d';' -f1 <<< "bla;bli;blu"
bla
$ man cut
$ man mkdir

@caracolito
Je doute qu'on puisse passer des paramètres à Windows afin qu'il ouvre un fichier à son démarrage.
Je pense que le moyen le plus simple de faire ce que tu voudrais, c'est de configurer Windows pour qu'il exécute tous les fichiers qu'il trouve dans un répertoire particulier. Ce répertoire serait ainsi un répertoire partagé par VMWare, et c'est là que tu copierais les fichiers que tu souhaites lancer.
Exemple :
1 - Lancement du script sur un fichier skp (genre clic droit puis "Ouvrir avec Windows")
2 - Le script copie le fichier en question dans le répertoire partagé par VMWare
3 - Le script lance Windows (du moins la machine virtuelle VMWare)
4 - Windows, a son démarrage, lance les fichiers présents dans le répertoire partagé par VMWare, soit, dans l'exemple sketchup

Cela dit, est-ce que ça vaut vraiment la peine de faire mettre en place ce genre de procédure vachement lourde ? Je trouve plus simple de lancer Windows manuellement et d'y ouvrir le fichier...

Vive le bash_completion !

[root ~]# invo[TAB] [TAB] [TAB]
acpid                       dbus                        keyboard-setup              portmap                     stop-bootlogd
acpi-support                dhcdbd                      killprocs                   procps                      stop-bootlogd-single
alsa-utils                  --disclose-deny             loadcpufreq                 --query                     sudo
amule-daemon                exim4                       module-init-tools           --quiet                     system-tools-backends
anacron                     --force                     mountoverflowtmp            rc                          --try-anyway
apache2                     gdm                         mysql                       rc.local                    udev
apmd                        hal                         mysql-ndb                   rcS                         udev-mtab
atd                         halt                        mysql-ndb-mgm               reboot                      umountfs
avahi-daemon                hdparm                      networking                  rmnologin                   umountroot
bluetooth                   --help                      network-manager             rsyslog                     urandom
bootlogd                    hibernate                   network-manager-dispatcher  screen-cleanup              vbesave
console-setup               ifupdown                    nfs-common                  sendsigs                    wpa-ifupdown
cpufrequtils                ifupdown-clean              --no-fallback               single                      x11-common
cron                        iptablesInit_BorX           openbsd-inetd               skeleton                    
cups                        kerneloops                  pcmciautils                 ssh                         
[root ~]# invoke-rc.d apa[TAB] [TAB] [TAB]
force-reload        restart             start-htcacheclean  stop                
reload              start               status              stop-htcacheclean   
[root ~]# invoke-rc.d apache2 rest[TAB]

Salut,

Super, gmarin !
Cette présentation a l'avantage de montrer dans le détail le fonctionnement de chaque requête.
Petite remarque pour la suite : l'ensemble mériterait un peu de factorisation, car les scripts en annexe deviennent vite indigestes
(fonction pour la requête de base, fonction pour le login, pour l'authentification, fonction générique pour aller chercher telle ou telle valeur, fonction pour interpréter le JSON, ...).
Ainsi, tu pourrais plus facilement éviter de passer systématiquement par des fichiers temporaires en pipant directement le résultat de tes fonctions.

Enfin, on commence à trouver des implémentations Shell de l'API Freebox !

À ce sujet, j'ai trouvé une excellente implémentation simple et efficace sur GitHub : https://github.com/JrCs/freeboxos-bash-api
Cherchant depuis longtemps à redémarrer ma Freebox automatiquement, j'ai repris ce Shell pour lui ajouter l'authentification et le reboot :
https://github.com/BorX/freeboxos-bash-api

J'ai fait ce script quand j'ai commencé à mettre à profit certains avantages des hardlinks.
En le présentant dans ce topic, c'est principalement ces avantages que je mettais en avant, tout en proposant aux intéressés d'utiliser le script.
Je ne connaissais pas encore FSlint à l'époque.
Depuis, j'ai joué avec et, (de mémoire,) FSlint propose bien plus de fonctionnalités que ce script, tant au niveau de la recherche des fichiers que des opérations qu'on peut ensuite effectuer.
Donc, utilise-le !

Après, si tu veux faire de l'automatisation, alors fais du scripting !
Pour ce faire, tu peux naturellement t'inspirer du script présenté ici
Cependant,
1) il faut que l'automatisation soit un besoin, et que ce besoin soit défini, sinon c'est pas la peine
2) il faut connaître (ou vouloir apprendre) le scripting

Note : ce script n'est pas vraiment optimisé pour de l'automatisation, puisqu'il génère un autre script qui peut être revu et modifié avant exécution.
C'est utile pour une exécution ponctuelle (et dans ce cas, il vaut mieux utiliser FSlint ), mais pour de l'automatisation, je rejoins l'avis de nesthib qui n'aime pas les scripts qui génèrent des scripts.

Bref, utilise FSlint
Mais fais gaffe à ce que tu fais, aussi...
C'est le genre d'outils avec lesquels une fausse manip' peut faire mal.
Alors fais des essais dans un répertoire de tests dans lequels tu auras balancé en doublons quelques gros fichiers, mp3, divx, quelques fichiers textes, des images, etc...

La question mérite d'être posée... à Canonical !

En effet, je trouve l'initiative de billou d'autant plus intéressante que son succès révèle une véritable volonté des utilisateurs d'Ubuntu à ne pas voir leur OS favori se transformer en une suite logicielle imposée.
(je n'avais pas pris le temps de le dire, c'est fait ; merci billou, excellente initiative ! )

Alors que billou fasse une slim à chaque release, ce serait cool (de sa part ), mais que Canonical propose sa version slim, ce serait même mieux !

Mais ce n'est clairement pas dans les aspirations de Canonical... et d'autres, avant le reste des utilisateurs d'Ubuntu, l'ont déjà compris :
OpenGeu et Crunchbang quittent le navire Ubuntu

Allez, bonus :
Pour les liens morts (qui pointent vers une cible inexistante), ne touche pas au lien (et le laisse donc mort).
Pour les liens pointant vers des répertoires, copie intégralement le répertoire cible (liens symboliques inclus).

#!/bin/bash
replaceLinkByTarget() {
    # On se positionne dans le répertoire du lien (pour les liens pointant vers des chemins relatifs)
    cd "$(dirname "$lien")"

    # On ne se soucie désormais que du nom du lien
    lien="$(basename "$lien")"

    # On définit la cible du lien
    orig="$(readlink "$lien")"

    # Si le lien pointe vers une cible inexistante
    [ -e "$orig" ] || return 1;

    # On efface le lien
    rm "$lien"

    # On copie la cible du lien à l'endroit du lien
    cp -a "$orig" "$lien"

    # On revient au répertoire précédent
    cd - >/dev/null
}

# Pour chaque paramètre
for lien in "$@"; do
  # S'il s'agit d'un lien symbolique
  [ -L "$lien" ] && replaceLinkByTarget "$lien";
done

Juste une piste...
Votre soucis est de connaître les requêtes qu'effectue une application flash afin de les réeffectuer, c'est bien ça ?
Dans ce cas, ne suffit-il pas de positionner une sorte de proxy relais entre votre navigateur et le serveur ? Un tel proxy peut ainsi être en mesure d'enregistrer les requêtes effectuées par votre navigateur, même celles effectuées par une application flash exécutée au sein de ce navigateur. Une fois les requêtes récupérées, une série de wget suffit pour les reproduire.

Ce système est notamment utilisé pour effectuer des tests de charge.
Par exemple avec JMeter, on le configure dans un premier temps en mode proxy. En configurant son navigateur pour qu'il utilise le proxy de JMeter, ce dernier enregistre l'ensemble des requêtes effectuées au sein du navigateur. On peut dès lors modifier ces requêtes à souhait et les réexecuter, dans un second temps, sans navigateur, donc sans application flash.

Sans forcément utiliser JMeter, il doit exister des proxies qu'on fait tourner en local et par lequel on fait passer le navigateur afin de tracer les requêtes qu'il effectue, et ainsi être en mesure de les réexécuter par des wget.

C'est, je pense, le meilleur moyen de connaître les interactions entre une application flash et un serveur.

Oui, JMeter n'est pas très intuitif au début...
De mémoire, il ne te faut activer que 2 composants : le proxy et le contrôleur enregistreur (par des clics droits sur le "Poste de travail de JMeter".
Une fois le proxy lancé (écoutant par exemple le port 8080) et le navigateur configuré pour l'utiliser (par exemple localhost:8080 comme proxy), le contrôleur enregistreur devrait afficher les requêtes effectuées par le navigateur.

La technologie utilisée sur le serveur n'a aucune importance (que ce soit du PHP, du .net, du Java, du Perl, du script Shell, ...). Le but n'est que de capturer des requêtes HTTP afin de les reproduire.

EDIT: Mais je pense qu'il existe des proxies pas trop lourds à mettre en place et parfaitement adaptés pour tracer les requêtes qu'ils voient passer...

Je comprends bien...

C'est bien la requête "attrapée" au moment d'un clic dans ton application flash ? ou bien au moment du chargement de ton application flash ?

Si c'est bien la requête "attrapée" au moment d'un clic dans ton application flash, ça semble bon.

C'est bien ce que j'ai expliqué. Mais en l'occurrence, il faut certainement pousser un peu plus loin, et pour ce faire, il faut connaître quelques principes de base du protocole HTTP.
wget est fait pour effectuer des requêtes HTTP, de la plus simple (comme montré dans mes exemples), aux requêtes les plus complexes (en GET, en POST, avec des paramètres, avec un maintien de session, ... il sait même effectuer des requêtes avec d'autres protocoles que HTTP).

Je pense que c'est parce qu'il faut effectivement pousser un peu plus la reproduction des requêtes.
Il convient donc d'étudier d'un peu plus près les requêtes effectuées par l'application flash en question, et même les autres avant.

C'est un bon début de réflexion. En effet, il est probable que le serveur n'accepte pas certaines opérations pour un utilisateur non connecté. Si c'est bien le cas, il faut paramétrer wget afin qu'il effectue une succession de requêtes avec un maintien de session.
Autre piste : par défaut, wget fait des requêtes GET. Si le serveur attend une requête POST, une requête GET ne marchera pas.

Bref, comme je le disais, il faut un minimum de connaissances du protocole HTTP, et il faut un peu potasser la doc de wget

http://princessleia.com/plug/2008-JP_bash_vs_dash.pdf
http://forum.ubuntu-fr.org/viewtopic.php?pid=2968428#p2968428

Bon.
En fait, je n'ai jamais été vraiment confronté à ce problème car j'ai généralement utilisé des variables globales du type :

$ROOT_URL='/appli1/';
$ROOT_PATH='/home/leUser/le/path/vers/appli1/';

Certes, il faut modifier ces variables dès qu'on change d'environnement, mais le désagrément est minime, surtout si ces variables sont externalisées dans un fichier à part, dédié à tout ce qui concerne la configuration de l'application.
En outre, on peut naturellement initialiser ces variables avec des données de $_SERVER, ce qui évite d'utiliser ce genre de "super-variables" un peu partout (et n'importe comment).

Edit :
Un de mes fichiers de configuration, typiquement, commence ainsi :

more conf/global.php 
<?
$PATH_ROOT = '/home/leUser/le/path/vers/appli1/';
$PATH_BIN = $PATH_ROOT.'bin/';
$PATH_LIB = $PATH_ROOT.'lib/';
$PATH_DAO = $PATH_ROOT.'dao/';
// ...

Ainsi, partout dans le reste de mon code, je fais référence à tel ou tel chemin avec des variables centralisées et globales, mais jamais en dur (ni en relatif ni en absolu car cela tendrait à rendre mon application difficile à maintenir).

Ça change tout
PhpMyAdmin attend le nom de l'utilisateur, tout comme en ligne de commande.
Et à ma connaissance, je n'ai jamais vu d'alias de login. Donc root, c'est root, et admin, s'il existe, c'est admin

Pense à mettre en [Résolu]