Ερώτηση για bash

[mrsaccess]

Εδώ πάντως ο κώδικάς σου λειτουργεί:

#!/usr/bin/env bash
PROFILABLE=0

function_1(){
    if true; then
        PROFILABLE=1
    fi
}

function_2(){
    #Δεν είναι ποτέ αληθής η ισότητα, χάνεται η τιμή 1 όταν και αν δωθεί
    if [[ "$PROFILABLE" -eq 1 ]]  ; then
        echo οκ
    fi
    echo $PROFILABLE    #Πάντα είναι 0
}

echo $PROFILABLE

function_1

function_2

Μήπως το do_something περιμένει να είναι exported η variable;

[guardianhelm]

Μήπως είναι θέμα shebang;

[imitheos]

Εδώ πάντως ο κώδικάς σου λειτουργεί:

Μήπως το do_something περιμένει να είναι exported η variable;

Όπως είπε και ο mrsaccess, ο κώδικας όπως μας τον δίνεις, λειτουργεί κανονικά. Στο bash αν δεν ορίσεις κάποια μεταβλητή σαν local, τότε είναι global και μπορείς να την αλλάξεις από παντού. Για να απαντήσουμε πρέπει να δούμε και το υπόλοιπο πρόγραμμα. Από αυτό που βλέπω, το μόνο που έρχεται στο μυαλό είναι να τρέχεις την συνάρτηση μέσα από κάποια μεταβλητή ώστε να αποθηκεύσεις αυτό που επιστρέφει, με συνέπεια να τρέχει σε κάποιο subshell.

#!/bin/bash

PROFILABLE=0

function_1(){
	echo Running function_1
        PROFILABLE=1
}

function_3(){
	echo Running function_3
        PROFILABLE=3
}

function_2(){
    #Δεν είναι ποτέ αληθής η ισότητα, χάνεται η τιμή 1 όταν και αν δωθεί
    if [[ "$PROFILABLE" -eq 1 ]]  ; then
	    echo Hello
    fi
    echo $PROFILABLE    #Πάντα είναι 0
}

echo Profilable before function1 = $PROFILABLE
function_1
echo Profilable after function1  = $PROFILABLE
function_2
PETRAN=$(function_3)
echo PETRAN = $PETRAN
echo Profilable after function3  = $PROFILABLE

Έξοδος:
% ./tmp.sh 
Profilable before function1 = 0
Running function_1
Profilable after function1 = 1
Hello
1
PETRAN = Running function_3
Profilable after function3 = 1

Όπως είδες από το παράδειγμα του mrsaccess και όπως βλέπεις και εδώ, η αλλαγή φαίνεται κανονικά εκτός της συνάρτησης function_1 και το Hello τρέχει στην function_2 οπότε η συνθήκη ικανοποιείται. Όταν όμως τρέχω την function_3 και αποθηκεύω την έξοδό της στην μεταβλητή PETRAN, αυτή τρέχει μέσα σε subshell οπότε αλλάζει μεν η μεταβλητή σε 3 αλλά όταν τελειώνει το subshell και επιστρέφουμε στο αρχικό, τότε εννοείται πως δεν υπάρχει η αλλαγή σε 3.

Edit: Ξέχασα να αναφέρω ότι το παραπάνω το έγραψα σαν παράδειγμα. Υπάρχουν πολλές περιπτώσεις στις οποίες μια εντολή θα τρέξει σε subshell.

[petran_18]

Προσπαθώ να αυτοματοποιήσω τις cflags για το PGO και για λόγους πειραματισμού/εφέ, ήθελα το portage να τυπώνει τα εκτελέσιμα που έχουν γίνει compile με PGO[1].

Ουσιαστικά έχω hardcoded τις κατηγορίες για τα πακέτα των οποίων θα εφαρμόζει τις εν λόγω flags και ανάλογα με το αν υπάρχουν ή όχι τα στατιστικά χρήσης (.gcda) θα πράττει τα δέοντα για να κάνει profiling το πακέτο.

cat /etc/portage/bashrc

#!/bin/bash

PGO_DIR=/var/tmp/pgo
PROFILE_DIR=${PGO_DIR}/${PN}
PROFILABLE=0
CFLAGS_PROFILE_GEN="-fprofile-generate=${PROFILE_DIR} -fprofile-arcs -fvpt" 
CFLAGS_PROFILE_USE="-fprofile-use=${PROFILE_DIR} -fprofile-correction" 
LDFLAGS_PROFILE_GEN="-fprofile-arcs" 

CFLAGS_CUSTOM="" 
LDFLAGS_CUSTOM=""

post_src_unpack() {
	if type epatch_user >& /dev/null; then
		cd "${S}"
		epatch_user
	fi

	case "${CATEGORY}" in
		*app-editor* | *dev-*  | *kde-* | *mail-client* | *media-video* | *www-client* )
		
		echo "1" > /tmp/profile
		elog "Will try to profile" "${PN}"

		if [ -d ${PROFILE_DIR} ] 
		then 
			elog "Running with PGO for the first time"
	  		CFLAGS="${CFLAGS} ${CFLAGS_CUSTOM} ${CFLAGS_PROFILE_USE}" 
			LDFLAGS="${LDFLAGS} ${LDFLAGS_CUSTOM}" 
		else
	 		CFLAGS="${CFLAGS} ${CFLAGS_CUSTOM} ${CFLAGS_PROFILE_GEN}" 
			LDFLAGS="${LDFLAGS} ${LDFLAGS_CUSTOM} ${LDFLAGS_PROFILE_GEN}" 
		fi
		CXXFLAGS="${CFLAGS}"
		
	esac
}


	
Spoiler: 
		
	
	

		

			
pre_src_prepare() {
    [[ ${EAPI:-0} == [012345] ]] || return
    if ! type estack_push > /dev/null 2>&1; then
        local estack_names="eshopts_push eshopts_pop evar_push evar_push_set evar_pop estack_push estack_pop"
        source <(awk "/^# @(FUNCTION|VARIABLE): / { p = 0 } /^# @(FUNCTION|VARIABLE): (${estack_names// /|})\$/ { p = 1 } p { print }" ${PORTDIR}/eclass/estack.eclass)
    fi
    if ! type epatch_user > /dev/null 2>&1; then
        local epatch_names="EPATCH_SOURCE EPATCH_USER_SOURCE epatch_user_death_notice epatch_user epatch"
        source <(awk "/^# @(FUNCTION|VARIABLE): / { p = 0 } /^# @(FUNCTION|VARIABLE): (${epatch_names// /|})\$/ { p = 1 } p { print }" ${PORTDIR}/eclass/epatch.eclass)
    fi

    epatch_user

    for name in $epatch_names; do
        unset $name
    done
    for name in $estack_names; do
        unset $name
    done
}

		
	


pkg_postinst() {
	#if PGO was applied, test if it succeded and chown the PROFILE_DIR
	read PROFILABLE < /tmp/profile && rm /tmp/profile
	if [[ "$PROFILABLE" -eq 1 ]]  ; then
		for i in `equery f ${PN} | grep "bin/"`;
		do
			if [[ -z `strings $i | grep profiling` ]]; then
				ewarn "This binary doesn't make use of PGO:" $i
			else
				elog  "This binary does make use of PGO:" $i
			fi
		done
	
	chown -R petros:petros "${PGO_DIR}"
	fi
}

Τελικά χρησιμοποίησα την άκομψη λύση του να γράψω σε εξωτερικό - έστω και στο /tmp - αρχείο.

[imitheos]

Δεν θυμάμαι πολύ καλά τα internals της portage αλλά ίσως να είναι αυτό που είπα πριν και η portage να τρέχει κάθε συνάρτηση σε δικό της subshell οπότε για αυτό να μην παίζει. Ίσως να λέω και χαζομάρες βέβαια.

Θυμάμαι όλοι να λένε within portage-bashrc lies madness και δεν πολυ ασχολήθηκα με bashrc.

Όσον αφορά τον κώδικα, λες if [ -d $PROFILE_DIR]; echo "Running for first time". Αν υπάρχει ο κατάλογος δεν σημαίνει ότι κάποια στιγμή ξαναέτρεξε το PGO ?

[petran_18]

Όσον αφορά τον κώδικα, λες if [ -d $PROFILE_DIR]; echo "Running for first time". Αν υπάρχει ο κατάλογος δεν σημαίνει ότι κάποια στιγμή ξαναέτρεξε το PGO ?

Ακριβώς, απο κάτω έπρεπε να μπει. Εκτός αν το έγραψα με την λογική ότι πρώτη φορά του κάνει actual profiling. Δεν θυμάμαι κιόλας

[imitheos]

Ακριβώς, απο κάτω έπρεπε να μπει. Εκτός αν το έγραψα με την λογική ότι πρώτη φορά του κάνει actual profiling. Δεν θυμάμαι κιόλας

Για αυτά τα πάντα μπαίνουν σε git repo και κάνεις commits που εξηγείς και την πιο μικρή αλλαγή

# cd /etc
# git log gentoo --pretty=oneline|wc -l
207
# git log slackware --pretty=oneline|wc -l
562

Στο /etc βέβαια έχεις ένα μικρό θέμα με τις άδειες μια και το git δεν κρατάει πληροφορίες για άδειες και χρήστες οπότε μπορεί μετά από κάποια αλλαγή να δεις το /etc/shadow να είναι root:root rw-r--r-- αλλά και για αυτό υπάρχουν λύσεις.

[mrsaccess]

Very interesting approach () αλλά αυτό με τα permissions και τα ownerships με τρομάζει!

[imitheos]

Very interesting approach () αλλά αυτό με τα permissions και τα ownerships με τρομάζει!

Ναι όντως είναι λίγο μανούρα με τις άδειες. Πιάστηκα όμως από τον εαυτό μου που έχει όλο το /etc σε αποθετήριο και ξέχασα να αναφέρω κάτι πολύ πιο απλό που κάνει όλος ο κόσμος και δεν υπάρχει πρόβλημα. Στο /etc μόνο 5-10 αρχεία έχουν διαφορετικό ownership από root:root ή διαφορετικές άδειες από 644. Από τα υπόλοιπα αρχεία πάρα πολλά δεν τα πειράζεις συχνά ή και καθόλου. Οπότε αυτό που κάνουν πολλοί είναι να έχεις σε ένα αποθετήριο μόνο τα αρχεία ρυθμίσεων που πειράζεις συχνά (πχ profile, zshrc, portage-bashrc, κτλ) και να έχεις symlinks στο /etc που να δείχνουν στο αποθετήριο. Αυτό εννοούσα σαν πρόταση στον petran πριν απλά όπως πάντα έγραψα ό,τι να ναι

[jim_p]

Θελω απο διαφορα addon.xml (ονομα του αρχειου), που ειναι σε διαφορετικους υποφακελους το καθενα αλλα ολα μεσα στο /storage/kodi/addons/ να σβηνω αυτοματα οποια γραμμη λεει πανω της "xbmc.service", πχ αυτη εδω θελω να φυγει ολοκληρη.

<extension point="xbmc.service" library="service.py" start="startup" />

---edit
Το δοκιμασα ετσι

# grep -rl "xbmc.service" /storage/.kodi/addons/ | xargs sed -i 'xbmc.service/d'

αλλα δεν φαινεται να τις σβηνει :/

---edit
Ειχα ξεχασει ενα / μετα το sed

# grep -rl "xbmc.service" /storage/.kodi/addons/ | xargs sed -i '/xbmc.service/d'

Τωρα δουλευει κανονικα, αλλα μπορει να γινει μονο με sed?

[imitheos]

Τωρα δουλευει κανονικα, αλλα μπορει να γινει μονο με sed?

find /storage/blah -name "addons.xml" -exec sed -i '/xbmc\.service/d' {} \;

Κάτι τέτοιο σου κάνει ?

Εναλλακτικά, αν το shell σου υποστηρίζει globbing υποφακέλων με τον μεταχαρακτήρα **, τότε μπορείς να χρησιμοποιήσεις μόνο του το sed.

Proof of concept:

% cd /tmp 
% mkdir -p storage/a1
% mkdir -p storage/a2/b1
% mkdir -p storage/c3/d2  

# Δημιουργία ενός αρχείου addons.xml σε κάθε άδειο κατάλογο
% find /tmp/storage -type d -empty -exec touch {}/addons.xml \;

% ls /tmp/storage/**/addons.xml
/tmp/storage/a1/addons.xml     /tmp/storage/c3/d2/addons.xml
/tmp/storage/a2/b1/addons.xml

Όπως βλέπεις, το shell έκανε expand την πρόταση με το ** σε όλα τα αρχεία addons σε όλους τους υποκαταλόγους.

[jim_p]

Ωραια, σημειωνω και την εκδοχη με το find να την εχω.

[jim_p]

Στο wiki του openelec για το autostart.sh* λεει πως το autostart.sh πρεπει να ξεκιναει με "{" και να τελειωνει με "} &". Για ποιο λογο?
Το αρχει δεν ειναι καποιο bash script, μιας και δεν ξεκιναει με #!/bin/bash, ουτε ειναι εκτελεσιμο

# file .config/autostart.sh
.config/autostart.sh: ASCII text

Αν ηταν εκτελεσιμο θα ελεγε κατι σαν αυτο

$ file bin/savoura.sh
bin/savoura.sh: Bourne-Again shell script, ASCII text executable

* http://wiki.openelec.tv/index.php/Autostart.sh

- - - Updated - - -

---edit
Το βρηκα το δευτερο κομματι. Παραμενει η ερωτηση για τις αγκυλες
http://openelec.tv/forum/64-installa...sh-file#137886

[imitheos]

Στο wiki του openelec για το autostart.sh* λεει πως το autostart.sh πρεπει να ξεκιναει με "{" και να τελειωνει με "} &". Για ποιο λογο?

Όχι με αγκύλες αλλά με παρενθέσεις. Στο εξηγεί γιατί. Μπορεί εσύ να έχεις βάλει εντολές οι οποίες να χρειάζονται πολύ χρόνο οπότε αυτό θα καθυστερήσει την εκκίνηση του προγράμματος. Βάζεις τις εντολές που θέλεις μέσα σε παρενθέσεις οπότε λες ότι θέλεις να τρέξουν μέσα σε subshell και έπειτα βάζεις και το & ώστε όλο αυτό το πράγμα να τρέξει στο παρασκήνιο.

Το αρχει δεν ειναι καποιο bash script, μιας και δεν ξεκιναει με #!/bin/bash, ουτε ειναι εκτελεσιμο

# file .config/autostart.sh
.config/autostart.sh: ASCII text

Αν ηταν εκτελεσιμο θα ελεγε κατι σαν αυτο

$ file bin/savoura.sh
bin/savoura.sh: Bourne-Again shell script, ASCII text executable

* http://wiki.openelec.tv/index.php/Autostart.sh

- - - Updated - - -

---edit
Το βρηκα το δευτερο κομματι. Παραμενει η ερωτηση για τις αγκυλες
http://openelec.tv/forum/64-installa...sh-file#137886

Το ό,τι δεν είναι εκτελέσιμο και ότι δεν αρχίζει με κάποιο shebang δεν σημαίνει ότι δεν είναι shell script απλά ότι δεν θα τρέξει αυτόνομα, όπως ανακάλυψες και μόνος σου. Σε πολλές περιπτώσεις (πχ /etc/profile.d, /etc/X11/xinitrc.d, κτλ) έχεις ένα κεντρικό shell script το οποίο "κάνει source" πολλά άλλα υπό ορισμένες συνθήκες. Αυτά δεν έχουν το κλασικό shebang #!/bin/τάδε επειδή "καλούνται" από αλλού.

% cat a.sh 
#!/bin/bash

echo Hello
# Κάνουμε source το αρχείο b.sh
. ./b.sh

% cat b.sh 
echo World

% chmod 755 a.sh 
% chmod 644 b.sh 
% ./a.sh 
Hello
World

Δηλώνοντας ". ./b.sh" (ή source ./b.sh) είναι σαν να είχαμε τα περιεχόμενα του αρχείου μέσα στο ίδιο το shell script οπότε δεν χρειάζεται το b.sh να είναι εκτελέσιμο.

[jim_p]

Παρενθεσεις? ΠΑΡΕΝΘΕΣΕΙΣ?!?! Και εγω εχω τοσα χρονια αγκυλες! Παω να τις αλλαξω τωρα.
Αν τις βγαλω εντελως, απλα θα περιμενει να τελειωσει οτι ειναι μεσα στις παρανθεσεις για να συνεχισει?

---edit
Τελικα μονο στο autostart.sh του pi zero ειχα αγκυλες και μεσα σε αυτες μονο ενα ακυρο rm, οποτε μικρο το κακο.