Niet alle Java-opdrachten voor Unix Shell zijn actief

Ik schrijf een applicatie die commando's naar een Unix-shell stuurt.

Ik heb nooit problemen met het uitgeven van cp- en chmod-commando's (die ik ken) maar om een ​​of andere reden zullen mv-commando's niet echt de bestanden verplaatsen die ik heb gebruikt?

Mijn code kan als volgt worden weergegeven:

    import java.io.IOException;
    public class ExecuteCommand {   
        public static void main(String[] args){
            ExecuteCommand exec = new ExecuteCommand("cp /some/directory/file.txt /some/directory/of/mine/");
            ExecuteCommand exec2 = new ExecuteCommand("chmod 666 /some/directory/of/mine/file.txt");
            ExecuteCommand exec3 = new ExecuteCommand("mv /some/directory/of/mine/file.txt /some/directory/of/mine/subDirectory/");
        }
        public ExecuteCommand(String command) {
            try {
                    System.out.println("EXECUTING!::" + command);       
                    Process child = Runtime.getRuntime().exec(command);             
            } catch (IOException e) {
            }
        }

    }

Ik heb geprobeerd om timers tussen de opdrachten in te zetten zonder dat er vooruitgang wordt geboekt om ervoor te zorgen dat% 100 van mijn opdrachten wordt verwerkt.

Houd er rekening mee dat mijn code voorbeeldinformatie bevat, als een deel van de syntaxis van het Unix-bestandssysteem onjuist is, vergeef me, en beschuldig het probleem daar niet de schuld van.

Als u meer informatie nodig hebt, vraag het dan en ik zal u zo snel mogelijk van dienst zijn

Bedankt jongens =)

0
Eerst moet u de IOExceptions in het catch-blok registreren (voor het testen zou e.printStackTrace() voldoende moeten zijn). Ten tweede, komt het probleem ook voor als je gewoon mv (exec3) uitvoert?
toegevoegd de auteur home, de bron
Met betrekking tot de uitzondering: gezien je voorbeeldprogramma kun je niet eens weten of er een IOException wordt gegenereerd - vanwege het lege catch-blok.
toegevoegd de auteur home, de bron
Nee, ik kan het commando van de constructor kopiëren en plakken, en het werkt prima.
toegevoegd de auteur Kamron K., de bron
En geen uitzondering wordt gegooid in het hoofdprogramma, ik heb dit voorbeeld geïmplementeerd ??
toegevoegd de auteur Kamron K., de bron
Ik ben het ermee eens, maar zoals ik al zei, dit is slechts een voorbeeld
toegevoegd de auteur Kamron K., de bron
In mijn echte code geef ik een dynamisch aantal commando's, soms in de honderden, afhankelijk van de dag en situatie, dus ik vraag of iemand dit probleem eerder heeft tegengekomen of eerder van dit probleem gehoord heeft
toegevoegd de auteur Kamron K., de bron
In mijn echte code, heb ik de uitzonderingen die nu naar de console afdrukken omdat deze niet is vrijgegeven uit gecontroleerde testfasen
toegevoegd de auteur Kamron K., de bron

1 antwoord

Een probleem met uw voorbeeldcode is dat u de uitzonderingen platdrukt. Als er een probleem is, gooit u het bewijs weg.

Een tweede probleem is dat u niet wacht op het voltooien van een opdracht voordat u de volgende start. Als een latere hangt af van een eerdere afwerking, zal het mislukken.

Een derde probleem is dat u de opdrachtretourneer/exit-codes niet controleert, of kijkt naar eventuele foutmeldingen die ze kunnen produceren. De foutmeldingen kunnen u vertellen waarom opdrachten niet werken ... als u de moeite neemt om ze op te halen en af ​​te drukken.

Het laatste (meta-) probleem is dat dit niet je echte code is ... dus we weten niet of de problemen die we zien alleen maar artefacten zijn van je Vraag. Geef alstublieft REAL-code op, niet een of andere gebrekkige versie met boogdlers.

0
toegevoegd
Gemerkt, bedankt voor het advies. Ik was niet op de hoogte van de methode waitFor() in de Process-bibliotheek. Ik zal het proberen, en als het probleem aanhoudt, zal ik op dat moment mijn eigen code gebruiken. Bedankt voor het beantwoorden van mijn vraag het beste wat je kon met mijn gebrek aan info, ik waardeer het echt =)
toegevoegd de auteur Kamron K., de bron
De waitFor() -methode is wat het deed, nu verloopt alles soepel en precies zoals verwacht.
toegevoegd de auteur Kamron K., de bron