'system' cannot properly start Linux shell scripts

Am 11.09.2011 18:55, schrieb Andreas Weidner:

I cannot get my EAGLE 5.11.02 (Linux) to properly execute shell scripts

with parameters: The shell script 'test.sh' contains the lines

#!/bin/bash

echo parameter=[$1]

and, when manually executed via

. test.sh abc

correctly outputs the text

parameter=[abc]

 

So far, so good. From EAGLE, using the ULP syntax

system(". test.sh abc");

by some reason only outputs

parameter=[]

 

Is there any logical reason why EAGLE should behave that way? Do I make

wrong assumptions somewhere (I normally do NOT use Linux and therefore

do NOT know too much about it)? I'm currently trying this on

Ubuntu 10.04 LTS - Lucid Lynx.

 

Andreas Weidner

 

Why would you want to source the script from withing the system()?

How about using system("test.sh abc") or system("./test.sh abc")?

I mean, the . (source) is only useful, when you want to put the

parameter into your current environment.

main() { system(". test.sh abc"); } behaves like the behaviour you describe.

--

Christoph

Am 11.09.2011 18:55, schrieb Andreas Weidner:

I cannot get my EAGLE 5.11.02 (Linux) to properly execute shell scripts

with parameters: The shell script 'test.sh' contains the lines

#!/bin/bash

echo parameter=[$1]

and, when manually executed via

. test.sh abc

correctly outputs the text

parameter=[abc]

 

So far, so good. From EAGLE, using the ULP syntax

system(". test.sh abc");

by some reason only outputs

parameter=[]

 

Is there any logical reason why EAGLE should behave that way? Do I make

wrong assumptions somewhere (I normally do NOT use Linux and therefore

do NOT know too much about it)? I'm currently trying this on

Ubuntu 10.04 LTS - Lucid Lynx.

 

Andreas Weidner

 

Why would you want to source the script from withing the system()?

How about using system("test.sh abc") or system("./test.sh abc")?

I mean, the . (source) is only useful, when you want to put the

parameter into your current environment.

main() { system(". test.sh abc"); } behaves like the behaviour you describe.

--

Christoph

Am 13.09.2011 11:08, schrieb Christoph Kukulies:

Why would you want to source the script from withing the system()?

I do not understand your question (I understand the WORDS, but not the

MEANING).

How about using system("test.sh abc") or system("./test.sh abc")?

See below.

I mean, the . (source) is only useful, when you want to put the

parameter into your current environment.

As stated, I do not know Linux well. Therefore, I first test things from

inside the shell, and afterwards try them with EAGLE's 'system' command.

From the shell, typing

   test.sh abc

didn't work at all. Neither did

   ./test.sh abc

(both just produce NOTHING but error messages). Absolutely the ONLY

thing that DID work from inside the shell was

   . test.sh abc

which, unfortunately, doesn't work together with the 'system' command.

Thanks for the tips, though. When I'm feeling extremely well and dare to

boot into the overly confusing Linux the next time, I'll check whether

your two suggestions work. If they DO, things are just getting even MORE

confusing with Linux, because that would not only mean that there are

cases when things work in the shell and NOT from EAGLE, but also the

other way round. VERY strange.

Andreas Weidner

Am 13.09.2011 13:41, schrieb Andreas Weidner:

Am 13.09.2011 11:08, schrieb Christoph Kukulies:

>> Why would you want to source the script from withing the system()?

    Typo: "from within"

Warum möchtest Du das Script "sourcen" (entspricht dem . (dot)-command)

 

I do not understand your question (I understand the WORDS, but not the

MEANING).

 

>> How about using system("test.sh abc") or system("./test.sh abc")?

 

See below.

 

>> I mean, the . (source) is only useful, when you want to put the

>> parameter into your current environment.

 

As stated, I do not know Linux well. Therefore, I first test things from

inside the shell, and afterwards try them with EAGLE's 'system' command.

From the shell, typing

test.sh abc

didn't work at all. Neither did

./test.sh abc

(both just produce NOTHING but error messages). Absolutely the ONLY

thing that DID work from inside the shell was

. test.sh abc

wie gesagt: versuch's mit system("./test.sh abc")

(vorher vielleicht noch ein chmod 755 test.sh)

which, unfortunately, doesn't work together with the 'system' command.

 

Thanks for the tips, though. When I'm feeling extremely well and dare to

boot into the overly confusing Linux the next time, I'll check whether

your two suggestions work. If they DO, things are just getting even MORE

confusing with Linux, because that would not only mean that there are

cases when things work in the shell and NOT from EAGLE, but also the

other way round. VERY strange.

 

Andreas Weidner

--

Christoph

Hallo Herr Kukulies,

Am 13.09.2011 16:52, schrieb Christoph Kukulies:

Warum möchtest Du das Script "sourcen" (entspricht dem . (dot)-command)

Ich bin bei Linux extrem haeufig schwer von Begriff, daher muss ich

leider nochmal nachfragen:

UEBERSETZEN konnte ich den Text schon, aber VERSTEHEN tue ich ihn auch

jetzt noch nicht: Ich weiss, was ein Skript ist (ich schreibe -zig). Ich

weiss, was ein Source Code ist (ich schreibe -zig). Aber was BEDEUTET

es, "ein Skript zu sourcen"? JEDES Skript ist fuer mich ein Source Code

irgendeiner Syntax. Kann man einen Source Code denn auch NICHT

"sourcen"? Mir ist diese ganze Nomenklatur VOELLIG unverstaendlich.

Falls Sie mir da weiterhelfen koennten, waere es vielleicht sinnvoll,

dies unter Umgehung des Forums zu tun, damit dies nicht mit

Erlaeuterungen gefuellt wird, die vielleicht jeder Linux-Benutzer

auswendig weiss, nur ich eben nicht...

Vielen Dank fuer die Muehe,

Andreas Weidner

Am 13.09.2011 16:52, schrieb Christoph Kukulies:

wie gesagt: versuch's mit system("./test.sh abc")

Hat alles nicht funktioniert.

(vorher vielleicht noch ein chmod 755 test.sh)

Aber DAS hat funktioniert und zeitigt folgende Veraenderungen:

  1. ". test.sh abc" vergisst zwar immer noch alle Parameter, aber

  2. "./test.sh abc" funktioniert jetzt OHNE Fehlermeldung.

Um ein Shellskript aus EAGLE heraus zu erzeugen und danach mehrfach mit

unterschiedlichen Parametern aufzurufen, ist also folgendes

durchzufuehren (fuer die Leute, die genauso doof sind wie ich):

  3. Skript erzeugen mit

       output("dateinamemitpfad") printf("%s","");

WUN-DER-BAR. Damit sollte ich unseren Simulatorsupport nicht nur unter

Windows, sondern auch fuer Linux und Mac hinkriegen. Danke fuer die Hilfe.

Andreas Weidner

Am 14.09.2011 23:18, schrieb Andreas Weidner:

Am 13.09.2011 16:52, schrieb Christoph Kukulies:

>> wie gesagt: versuch's mit system("./test.sh abc")

 

Hat alles nicht funktioniert.

 

>> (vorher vielleicht noch ein chmod 755 test.sh)

 

Aber DAS hat funktioniert und zeitigt folgende Veraenderungen:

1. ". test.sh abc" vergisst zwar immer noch alle Parameter, aber

2. "./test.sh abc" funktioniert jetzt OHNE Fehlermeldung.

 

Um ein Shellskript aus EAGLE heraus zu erzeugen und danach mehrfach mit

unterschiedlichen Parametern aufzurufen, ist also folgendes

durchzufuehren (fuer die Leute, die genauso doof sind wie ich):

3. Skript erzeugen mit

output("dateinamemitpfad") printf("%s","<skriptinhalt>");

4. Skript-Benutzerrechte veraendern mit

system("chmod 755 'dateinamemitpfad'");

5. Skript aufrufen mit

system("'dateinamemitpfad' <parameter>");

 

WUN-DER-BAR. Damit sollte ich unseren Simulatorsupport nicht nur unter

Windows, sondern auch fuer Linux und Mac hinkriegen. Danke fuer die Hilfe.

 

Andreas Weidner

Zur Erläuterung Linux-Grundlagen,  drei markante Unterschiede zu Windows:

a)  Bei einer Kommandoeingabe (Skript,  Anwendungsprogramm etc.) sucht

Linux das Kommando im vorgegebenen Suchpfad (den anschauen: echo $PATH

),  aber aus Sicherheitsgründen absichtlich NICHT im aktuellen

Verzeichnis.

Einem Kommando im aktuellen Verzeichnis muss man also IMMER ./ für

"hier" voranstellen (z.B. ./meinscript.sh ),  damit es überhaupt

gefunden wird.  Oder den kompletten Pfad /home/meinname/meinscript.sh .

Das könnte man zwar ändern ( . in den Suchpfad mit aufnehmen),  ist aber

nicht empfehlenswert.

Fertige Kommandos für alle Benutzer verlegt man üblicherweise nach

/usr/local/bin (dazu root=Administrator-Rechte nötig);  das ist im

Suchpfad,  dann klappt auch der einfache Aufruf mit zB meinscript.sh,

und zwar für alle Benutzer.

Für rein persönliche Kommandos kann man sich ein Unterverzeichnis bin

anlegen (also /home/meinname/bin ) und das in den Pfad aufnehmen (

PATH=$PATH:$HOME/bin )  Stellt man es vornean ( PATH=$HOME/bin:$PATH ),

  dann werden eigene Kommandos gegenüber gleichnamigen Systemkommandos

vorrangig.

b) Damit ein Kommando auch ausgeführt werden kann,  muss das Dateirecht

x = Ausführbar für den betreffenden Benutzer gesetzt sein (das gibt es

in Windows so nicht).  Bei Downloads oder mit dem Editor verfassten

Skripten ist das zunächst nicht der Fall,  also manuell noch setzen per

chmod 755 meinscript.sh .  (oder 750,  wenn es nur für eine bestimmte

Benutzergruppe ausführbar sein soll;  oder 700,  wenn nur für mich.  Das

steht oktal für je drei bits read / write /execute für Eigentümer /

Benutzergruppe / Alle)

c) Die Dateiendung "Extension" ist für Linux unwichtig,  rein kosmetisch

für den Menschen.  Kommandos werden auf ihren Inhalt überprüft,  wie sie

ausgeführt werden müssen.  Daher in Shellscripten als erste (quasi

Kommentar-) Zeile z.B.

#!/bin/sh

als Anweisung, dieses Script mit dem Standard-Shell-Interpreter

auszuführen.  Oder zB #!/bin/perl für ein Perl-Programm usw.

Ohne diese "Hash-Bang-Zeile" müsste man das explizit angeben,  zB als

/bin/sh ./meinscript.sh

Grüße,  Hans

Am 14.09.2011 10:40, schrieb Andreas Weidner:

Hallo Herr Kukulies,

 

Am 13.09.2011 16:52, schrieb Christoph Kukulies:

>> Warum möchtest Du das Script "sourcen" (entspricht dem . (dot)-command)

 

Ich bin bei Linux extrem haeufig schwer von Begriff, daher muss ich

leider nochmal nachfragen:

 

UEBERSETZEN konnte ich den Text schon, aber VERSTEHEN tue ich ihn auch

jetzt noch nicht: Ich weiss, was ein Skript ist (ich schreibe -zig). Ich

weiss, was ein Source Code ist (ich schreibe -zig). Aber was BEDEUTET

es, "ein Skript zu sourcen"? JEDES Skript ist fuer mich ein Source Code

Hallo Herr Weidner,

Der alleinstehende "." (Punkt, dot) ist ein eingebautes (built-in)

(bourne) shell Kommando.

csh (C-shell) kennt dafür "source" (glaube, in der bourne shell ist es

auch alternativ zu "." möglich).

Warum ihm der Begriff "source" (Quelle) gegeben wurde, kann ich im

Moment auch nicht genau sagen. Vielleicht als Gegensatz zur sink (Senke).

Ich habe gerade noch mal im Buch von Kochan/Woods "UNIX Shell

Programming" nachgesehen. Dort steht:

...there is a shell built-in command . ((pronounced "dot") whose general

format is

. file

and whose purpose is to execute the contents of file in the *current

shell*. That is, commands from file are executed by the current shell

*as if they were typed at the point". A subshell is not spawned by the

program. The shell uses your PATH variable to find file, just like it

does when executing other programs.

Nun kann man vielleicht "source" besser verstehen. file wird als Quelle

benutzt, aus der ihr Inhalt in den Punkt "fließt".

irgendeiner Syntax. Kann man einen Source Code denn auch NICHT

"sourcen"? Mir ist diese ganze Nomenklatur VOELLIG unverstaendlich.

 

Falls Sie mir da weiterhelfen koennten, waere es vielleicht sinnvoll,

dies unter Umgehung des Forums zu tun, damit dies nicht mit

Erlaeuterungen gefuellt wird, die vielleicht jeder Linux-Benutzer

auswendig weiss, nur ich eben nicht...

Auf die Gefahr hin, daß ich gelyncht werde, hab' ich es jetzt trotzdem

hier hineingeschrieben.

 

Vielen Dank fuer die Muehe,

Andreas Weidner

--

Christoph Kukulies