Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.os.unix.linux.misc > #110940 > unrolled thread

MC

Back to article view | Back to de.comp.os.unix.linux.misc

Contents

  MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-11 18:00 +0200
    Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-11 18:02 +0200
    Re: MC Lutz Falke <lutzfalke@gmx.de> - 2020-06-11 20:47 +0000
    Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-11 23:08 +0200
      Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-11 23:46 +0200
        Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-12 00:27 +0200
          Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-12 01:38 +0200
            Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-12 10:17 +0200
              Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-12 11:25 +0200
                Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-12 13:01 +0200
                  Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-12 15:34 +0200
                    Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-12 19:41 +0200
                      Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-12 23:38 +0200
                        Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-13 09:00 +0200
                          Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-13 20:08 +0200
                            Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-13 21:24 +0200
                Re: MC Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-06-12 20:15 +0200
                  Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-12 23:50 +0200
                    Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-13 10:19 +0200
                      Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-13 20:12 +0200
                        Re: MC Ulli Horlacher <framstag@rus.uni-stuttgart.de> - 2020-06-14 09:25 +0000
                        Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-14 13:02 +0200
                          Re: MC Claus Reibenstein <4spamersonly@kabelmail.de> - 2020-06-14 16:58 +0200
                            Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-14 17:03 +0200
                              Re: MC Claus Reibenstein <4spamersonly@kabelmail.de> - 2020-06-14 19:06 +0200
                                Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-14 22:42 +0200
                                  Re: MC Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2020-06-15 00:16 +0200
                                    Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-15 22:34 +0200
                                      Re: MC Hergen Lehmann <hlehmann.expires.5-11@snafu.de> - 2020-06-16 09:55 +0200
                                        Re: MC Stefan Reuther <stefan.news@arcor.de> - 2020-06-16 18:42 +0200
                                          Re: root sudo (was:MC) Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-17 07:02 +0200
                                            Re: root sudo (was:MC) Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-17 07:25 +0200
                                            Re: root sudo (was:MC) Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-06-17 12:51 +0200
                                              Re: root sudo Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-17 14:34 +0200
                                                Re: root sudo Marc Haber <mh+usenetspam1118@zugschl.us> - 2020-06-17 17:50 +0200
                                                  Re: root sudo Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-17 19:03 +0200
                                                    Re: root sudo Helmut Waitzmann Anti-Spam-Ticket.b.qc3c <nn.throttle@xoxy.net> - 2020-06-17 20:59 +0200
                                              Re: root sudo Helmut Waitzmann Anti-Spam-Ticket.b.qc3c <nn.throttle@xoxy.net> - 2020-06-17 21:03 +0200
                                                Re: root sudo Hermann Riemann <nospam.ng@hermann-riemann.de> - 2020-06-18 06:57 +0200
                                            Re: root sudo (was:MC) "Gerald E:scher" <Spamer@fahr-zur-Hoelle.org> - 2020-06-17 17:02 +0000
                                        Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-16 21:26 +0200
                                Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-14 22:06 +0200
                              Re: MC Christian Garbs <mitch@cgarbs.de> - 2020-06-16 09:00 +0200
                                Re: MC Ulf Volmer <u.volmer@u-v.de> - 2020-06-16 09:10 +0200
                                  Re: MC Christian Garbs <mitch@cgarbs.de> - 2020-06-18 17:16 +0200
                            Re: MC Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-14 17:28 +0200
                              Re: MC Claus Reibenstein <4spamersonly@kabelmail.de> - 2020-06-14 19:16 +0200
                                Re: MC Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-14 20:32 +0200
                                  Re: MC Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-06-14 23:05 +0200
                                    Re: MC Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-15 12:43 +0200
                                      Re: MC Marcus Jodorf <trap@killfile.de> - 2020-06-15 14:45 +0200
                                      Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-15 23:20 +0200
                    Re: MC Diedrich Ehlerding <diedrich.ehlerding@t-online.de> - 2020-06-13 13:59 +0200
                      Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-13 20:18 +0200
                        Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-14 13:02 +0200
                    Re: MC Sieghard Schicktanz <Sieghard.Schicktanz@SchS.de> - 2020-06-13 21:35 +0200
                      Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-14 06:55 +0200
                        Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-14 18:06 +0200
                          Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-14 19:37 +0200
                            Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-14 22:50 +0200
                              Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-15 08:45 +0200
                                Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-15 12:26 +0200
                                Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-15 23:08 +0200
                                  Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-16 10:48 +0200
                        Re: MC Lutz Falke <lutzfalke@gmx.de> - 2020-06-14 17:09 +0000
                      Re: MC Lutz Falke <lutzfalke@gmx.de> - 2020-06-14 18:25 +0000
                        Re: MC Lutz Falke <lutzfalke@gmx.de> - 2020-06-14 20:04 +0000
                        Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-15 22:44 +0200
                        Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-16 02:50 +0200
                          Re: MC Friedhelm Waitzmann <usenetf2020.fwnsp@spamgourmet.com> - 2020-06-30 15:17 +0000
                        Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-17 00:22 +0200
            Re: MC Lutz Golke <despammed@freenet.de> - 2020-06-12 11:36 +0200
      Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-13 10:56 +0200
        Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-13 12:32 +0200
          Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-13 12:46 +0200
          Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-13 18:19 +0200
            Re: MC Gunter Gutzeit <gunter.gutzeit@arcor.de> - 2020-06-13 21:04 +0200
              Re: MC Martin Schnitkemper <news.trash.5.mschnitk@spamgourmet.com> - 2020-06-14 13:01 +0200
              Re: MC Helmut Waitzmann <nn.throttle@xoxy.net> - 2020-06-14 15:16 +0200
        Re: MC Matthias Gerds <m.gerds@posteo.de> - 2020-06-13 21:45 +0200

Page 4 of 4 — ← Prev page 1 2 3 [4]

#111054

Helmut Waitzmann schrieb am So 14.06.2020 22:50:42 +0200:

> Gunter Gutzeit <gunter.gutzeit@arcor.de> :
>> Helmut Waitzmann schrieb am So 14.06.2020 18:06:59 +0200:  
>>> Gunter Gutzeit <gunter.gutzeit@arcor.de> :  
> 
>>>> Warum funktioniert das in Debian auch ohne Aufruf des 
>>>> mc-wrapper.sh?  
>>> 
>>> Da müsste man mal fahnden, was geschieht, wenn man den Mc 
>>> aufruft.  Ich habe ihn bei mir nicht installiert, deshalb kann 
>>> ich nicht selbst nachsehen. 
>>> 
>>> Den Mc ruft man mit dem Kommando «mc» auf?  Dann wäre das 
>>> Kommando
>>> 
>>>   command -V -- mc
>>> 
>>> ein erster Ansatzpunkt, dahinterzukommen, was da geschieht.  
>>>  
>> 
>> gunter@hp1:~$ command -V -- mc
>> mc is hashed (/usr/bin/mc)
>> 
>> root@hp1:~# command -V -- mc
>> mc ist /usr/bin/mc  
> 
> Danke.

Ich habe zu danken.
 
> Wenn der Midnight‐Commander also wirklich mittels des Kommandos 
> «mc» aufgerufen wird, das Kommando «mc» aber nichts anderes tut, 
> als das Programm «/usr/bin/mc» zu starten, dann ist 
> ausgeschlossen, dass das Programm «/usr/bin/mc» den es aufrufenden 
> Shell (unmittelbar) veranlassen kann, sein Arbeitsverzeichnis auf 
> das zu wechseln, was innerhalb des «mc» zuletzt angezeigt wurde. 

Das deckt sich mit meinen praktischen Erfahrungen. Es gibt
vergleichbare Linux-Dateimanager, die verhalten sich anders.

Ja, das wäre nicht schlecht, wenn ich meinen MC, skript-gesteuert
zumindest zeitweise, um ein solches Feature erweitern könnte.   

> Damit so etwas doch möglich ist, müsste der aufrufende Shell auf 
> irgendeine andere Weise benachrichtigt werden (vielleicht mit 
> einem Signal, das er mit einem Signalbehandler abfängt; das 
> Kommando
> 
>   trap -p

Den Befehl kannte ich bisher nicht und eröffnet ja ganz neue
Möglichkeiten. Trap ist offenbar das Gegenstück zu kill. Wow - damit
lässt sich ja sogar Signal EXIT abfangen - klasse! Vor dem Problem
habe auch schon mal gestanden und habe es dann etwas umständlich dadurch
gelöst, vor Beendigung des Skripts einen weiteren Kindprozess zu
starten, der nach Beendigung des Hauptprozesses, seine Aufgaben im
Hintergrund weiter erledigt, ohne durch den Hauptprozess gestört werden
zu können. 
 
> sollte es an den Tag bringen), dass er jetzt doch bitte eine 
> bestimmte Shell‐Skript‐Datei abarbeiten möge: eine 
> Shell‐Skript‐Datei, in die «/usr/bin/mc» ein «cd»‐Kommando 
> geschrieben hat. 

Da ich den Trap-Befehl mangels Praxis-Erfahrung aber zur Zeit noch nicht
richtig in mein Weltbild einsortiert habe, fällt es mir allerdings
schwer zu erkennen, wie mir die Option -p (display the trap commands
associated with each SIGNAL_SPEC) im Umgang mit meinem MC jetzt
weiterhelfen könnte.

-- 
Gunter
https://guntergutzeit.de.cool

[toc] | [prev] | [next] | [standalone]

#111057

Gunter Gutzeit (ich selbst) schrieb am Mo 15.06.2020 08:45:28 +0200:

> Helmut Waitzmann schrieb am So 14.06.2020 22:50:42 +0200:

>> Wenn der Midnight‐Commander also wirklich mittels des Kommandos 
>> «mc» aufgerufen wird, das Kommando «mc» aber nichts anderes tut, 
>> als das Programm «/usr/bin/mc» zu starten, dann ist 
>> ausgeschlossen, dass das Programm «/usr/bin/mc» den es aufrufenden 
>> Shell (unmittelbar) veranlassen kann, sein Arbeitsverzeichnis auf 
>> das zu wechseln, was innerhalb des «mc» zuletzt angezeigt wurde.   
> 
> Das deckt sich mit meinen praktischen Erfahrungen. Es gibt
> vergleichbare Linux-Dateimanager, die verhalten sich anders.
> 
> Ja, das wäre nicht schlecht, wenn ich meinen MC, skript-gesteuert
> zumindest zeitweise, um ein solches Feature erweitern könnte.   

Derweil habe ich für mich folgende (Zwischen-)Lösung entwickelt und für
mein Mc-Nutzermenü ein Skript geschieben, dass sowohl in einer User-
Hauptshell als auch in einer Root-Hauptshell bei mir unter Debian
funktioniert. Man muss wissen, dass der Mc immer in einer Sub-Shell
läuft und für seine interne Programmausführung wohl weitere Unter-Shells
nutzt.

----------------------------------------------------------------------

x Verz speichern   -> Verz-Wechsel mittels Bash-History
	printf "\033c"
	echo "cd %d" >> ~/.bash_history
	echo ""
	echo "Man muss wissen, dass der MC in einer Sub-Shell läuft. Normalerweise"
	echo "sind ausgeführte Befehle und besuchte Verzeichnisse deshalb nach"
	echo "Programmbeendigung ohne Rückgriff auf die Log-Dateien für eine direkte"
        echo "Nutzung in der Haupt-Shell verloren."
	echo ""
	echo "Folgender Befehl zum Verzeichnis-Wechsel"
	echo "cd %d"
	echo "wurde in der Bash-History gespeichert!"
	echo ""
	echo "Dieser Befehl kann nach Beendigung dieser MC-Sitzung in der Haupt-Shell"
	echo "unter Rückgriff auf die vorhanden Einträge der .bash_history mit der"
	echo "PfeilUp-Taste aktiviert und mit der Enter-Taste ausgeführt werden."
	echo ""
	read -p "Enter-Taste drücken, um diese Ansicht zu beenden >" x

----------------------------------------------------------------------

Um die History dazu zu bewegen, nicht in den Buffer, sondern sofort in
die .bash_history zu schreiben, muss folgende Zeile in die .bashrc (am
besten sowohl auf User- wie auf Root-Ebene) hinzugefügt werden:

PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND"

Meine User.bashrc und Root.bashrc verfügt deshalb hinsichtlich der
History-Steuerung über folgende Eintäge:

----------------------------------------------------------------------  

# don't put duplicate lines or lines starting with space in the history.
# See bash(1) for more options
HISTCONTROL=ignoreboth

# append to the history file, don't overwrite it
shopt -s histappend
PROMPT_COMMAND="history -a; history -c; history -r; $PROMPT_COMMAND"

# for setting history length see HISTSIZE and HISTFILESIZE in bash(1)
HISTSIZE=1000
HISTFILESIZE=2000

----------------------------------------------------------------------

Mit dieser Lösung kann ich leben. Weitere Ideen sind willkommen.

-- 
Gunter
https://guntergutzeit.de.cool

[toc] | [prev] | [next] | [standalone]

#111073

Gunter Gutzeit <gunter.gutzeit@arcor.de>:
>Helmut Waitzmann schrieb am So 14.06.2020 22:50:42 +0200:

>> Damit so etwas doch möglich ist, müsste der aufrufende Shell 
>> auf irgendeine andere Weise benachrichtigt werden (vielleicht 
>> mit einem Signal, das er mit einem Signalbehandler abfängt; das 
>> Kommando
>>
>>   trap -p
>
>Den Befehl kannte ich bisher nicht und eröffnet ja ganz neue 
>Möglichkeiten. Trap ist offenbar das Gegenstück zu kill.

Ja, kann man so sagen.  


Ein ehrlich gemeinter Rat:  Lege jetzt das Shell‐Handbuch zur 
Seite und nimm statt dessen ein Buch her, das erklärt, wie Unix 
oder Linux auf der Systemaufruf‐Ebene funktioniert.  Arbeite Dich 
durch die Kapitel durch, die sich mit Prozessen, insbesondere der 
Eltern‐Kind‐Beziehung, Prozessgruppen, dem Verschicken von 
Signalen (der Systemaufruf «kill») und dem Empfang von Signalen 
(dem historischen Systemaufruf «signal», die sehr verbesserten 
neueren Systemaufrufe zur Signalbehandlung wie beispielsweise 
«sigaction», «sigprocmask», …) befassen.  Wenn Du das hinter Dir 
hast, komm zum Shell‐Handbuch zurück.  Dann wirst Du auf einen 
Schlag verstehen, wie das Shell‐Kommando «trap» funktioniert. 

Außerdem kannst Du als Anfang auch mal ins Handbuch «signal(7)» 
schauen. 

>Wow - damit lässt sich ja sogar Signal EXIT abfangen - klasse! 


EXIT ist ein simuliertes Signal, das es nicht gibt.  Der Shell 
ruft die für das «Signal» «EXIT» eingetragene Aktion aus eigenem 
Antrieb auf, nicht, weil er mit einem Signal getreten wird. 

>Da ich den Trap-Befehl mangels Praxis-Erfahrung aber zur Zeit 
>noch nicht richtig in mein Weltbild einsortiert habe, fällt es 
>mir allerdings schwer zu erkennen, wie mir die Option -p (display 
>the trap commands associated with each SIGNAL_SPEC) im Umgang mit 
>meinem MC jetzt weiterhelfen könnte.

Sie könnte zeigen, ob der Mc‐Wrapper mit dem Shell vereinbart hat, 
dass der Shell beobachtet, ob er ein bestimmtes Signal (von dem er 
dann annimmt, dass es vom Midnight‐Commander verschickt wurde) 
erhalten hat, um darauf zu reagieren.  Aber das halte ich für eher 
unwahrscheinlich, denn andere Beiträge dieser Diskussion lassen 
inzwischen vermuten, dass da verschiedene Teilnehmer von 
verschiedenen Dingen reden, aber der Meinung sind, den selben 
Sachverhalt zu meinen. 

[toc] | [prev] | [next] | [standalone]

#111093

Helmut Waitzmann schrieb am Mo 15.06.2020 23:08:58 +0200:

> Ein ehrlich gemeinter Rat: Lege jetzt das Shell‐Handbuch zur 
> Seite und nimm statt dessen ein Buch her, das erklärt, wie Unix 
> oder Linux auf der Systemaufruf‐Ebene funktioniert. [...] 

Ok - Danke - sobald ich Zeit und Ruhe finde, werde ich mich mit der
wichtigen Systemaufruf-Thematik beschäftigen.

>> Da ich den Trap-Befehl mangels Praxis-Erfahrung aber zur Zeit 
>> noch nicht richtig in mein Weltbild einsortiert habe, fällt es 
>> mir allerdings schwer zu erkennen, wie mir die Option -p (display 
>> the trap commands associated with each SIGNAL_SPEC) im Umgang mit 
>> meinem MC jetzt weiterhelfen könnte.  
> 
> Sie könnte zeigen, ob der Mc‐Wrapper mit dem Shell vereinbart hat, 
> dass der Shell beobachtet, ob er ein bestimmtes Signal (von dem er 
> dann annimmt, dass es vom Midnight‐Commander verschickt wurde) 
> erhalten hat, um darauf zu reagieren. Aber das halte ich für eher 
> unwahrscheinlich, denn andere Beiträge dieser Diskussion lassen 
> inzwischen vermuten, dass da verschiedene Teilnehmer von 
> verschiedenen Dingen reden, aber der Meinung sind, den selben 
> Sachverhalt zu meinen. 

Dass der MC Signals verschickt, auf die der Mc-Wrapper wartet, halte ich
auch für äußerst unwahrscheinlich. Wie die MC-Sub-Shell-Problematik
zeigt, wollten die MC-Entwickler m.E. den MC ganz bewußt möglichst
abgeschottet und geschützt vom Rest-System bzw der Haupt-Shell
betreiben. Vergleichbare Linux-Datei-Manager verhalten sich anders.

Nun gut, da mich die Mc‐Wrapper-Problematik ohnehin praktisch nicht
betrifft, hat sie für mich derzeit nur eine akademische Bedeutung.

Soweit Du zuvor das Problem eines gewollten Wechsels des Arbeits-
verzeichnisses auf Haupt-Shell-Ebene angesprochen hattest, habe ich mit
meinem laienhaften Linux-Verständnis eine praktische Lösung gefunden,
aus dem Gefängnis der MC-Sub-Shell, die vom MC vorgehaltenen Infos in
die Haupt-Shell durch zu stoßen und wahlweise nach Rückkehr auf die
Haupt-Shell-Ebene mit 2 Tastaturanschlägen nutzbar zu machen.  

-- 
Gunter
https://guntergutzeit.de.cool

[toc] | [prev] | [next] | [standalone]

#111040

Gunter Gutzeit schrieb:
> Sieghard Schicktanz schrieb am Sa 13.06.2020 21:35:29 +0200:
>
>> [...]  und das wird mittels des
>> "alias mc='. /usr/share/mc/bin/mc-wrapper.sh'" gesetzt. [...]

[Inhalte "mc-wrapper.sh" und "mc.sh"]

> Warum funktioniert das in Debian auch ohne Aufruf des mc-wrapper.sh?

Was funktioniert wie? Ich habe den Eindruck, wir reden hier ganz
gehörig aneinander vorbei. Martin hat das Verhalten vom mc in
<54bfrg-0bs.ln1@martin.motzarella.org> beschrieben, genauer kann ich
das auch nicht.

Wenn ich Matthias richtig verstanden habe, geht es ihm um folgendes:

  *Nachdem* er den mc verlässt (F10-quit), soll sich die Shell (aus
  der er den mc aufgerufen hat) in dem Verzeichnis befinden, dass er
  im mc (im zuletzt aktiven Panel) zuletzt bearbeitet hat.

Die Option "Auto save panels setup" hat darauf keinerlei Einfluß.

Lutz

[toc] | [prev] | [next] | [standalone]

#111043

Sieghard Schicktanz schrieb:
> Hallo Matthias,
>
> Du schriebst am Fri, 12 Jun 2020 23:50:35 +0200:
>
>> > Ich les' immer "sudo"-irgendwas und nimmt nicht die root-Einstellungen -
> ...
>> > schaltet er für den Aufruf auf das "$HOME" des dafür eingesetzten
>> > Benutzers, bei einem "root"- Aufruf also das "$HOME" von
>> > "root" ("/root").  
>> 
>> Geht auch nicht. Ist ja eigentlich auch nur eine Kleinigkeit, die mich 
>> stört:
>> Unter <Benutzer> bleibt der im MC aktuell gewählte Pfad beim Verlassen 
>> (F10) erhalten, unter 'sudo mc' nicht, sondern er kehrt stets zu dem 
>> Pfad zurück, von dem aus ich ihn aufgerufen habe. Alle anderen 
>> Einstellungen werden artig übernommen.

Von sudo war im OP noch keine Rede. Zusammen mit sudo funktioniert das
so nicht. Siehe unten.

> Ahso. Dann liegt das eher daran, daß mit dem "sudo"-Aufruf die Aliases des
> Benutzers ungültig werden. Wenn der "mc" beim Aufruf in das zuletzt
> benutzte Verzeichnis wechseln (!) soll, dann muß er dazu über das schon
> angesprochene "wrapper"-Skript aufgerufen werden, und das wird mittels des
> "alias mc='. /usr/share/mc/bin/mc-wrapper.sh'" gesetzt. Du kannst das
> feststellen, indem Du "sudo bash -c alias mc" eingibst. (Die "bash" muß hier
> explizit vorgeschaltet weden, weil die "alias"-Einstellungn "ihr gehören",
> d.h. nur in dieser vorhanden sind.) Wahrscheinlich erfolgt daraufhin gar
> keine Ausgabe, was heißt, daß für diesen Aufruf kein solches Alias
> existiert.

Möglich, das spielt aber keine Rolle.

> Wenn Du dafür dasselbe Verhalten wie für den Benutzer haben willst, mußt Du
> die von "sudo" benutzte Shell (wohl "bash") dazu bringen, diesen Alias
> anzulegen. Dafür gibt's mehreeMöglichkeiten, eine davon wäre, den in Deinem
> "~/.bashrc" einzutragen, bzw. in dem von "root".
> Es gibt auch noch die Möglichkeit, das automatisch für alle Benutzer inkl.
> "root" zu setzen, falls gewünscht. Das muß dann natürlich "root" machen,
> weil dazu in "/etc/profile.d" ein Eintrag angelegt werden muß. Für die
> "bash" als Benutzer-Shell muß das ein File mit der Endung ".sh" sein, das
> dann die obige "alias"-Definition enthält. Ein solches liefert der "mc" in
> seinem Systemverzeichnis ("/usr/lib/mc" o.ä.) als "mc.sh" schon fertig mit.

Nein das funktioniert so nicht. Die Verzeichniswechselei wird durch
den "sudo"-Befehl unterbrochen, weil da noch mindestens ein
zusätzlicher Prozess beteiligt ist. tlrd; Das "sudo" muss in den
Wrapper.

Erklärender Einschub:

Grob gesagt, ist die Struktur folgendermaßen:
1) Die Shell (Elternprozess) startet mc (Kindprozess)

bzw.

2) Die Shell (Großelternprozess) startet sudo (Elternprozess).
   sudo startet mc (Kindprozess)

Nun ist es so, dass ein Kindprozess (ausser eventuell durch explizte
Kommunikation, die hier aber nicht vorgesehen ist) keinen Einfluß auf
das Arbeitsverzeichnis (current working directory) des Elternprozesses
hat. Darum der Klimmzug mit dem Wrapper.

Selbst wenn man im zweiten Fall (mit sudo) dort den Wrapper einbaut,
bringt das nichts. Dann ändert sich zwar kurzzeitig das
Arbeitsverzeichnis des sudo-Prozesses, das hat aber keinen Einfluß auf
die ursprünglich aufrufende Shell.

Lösungsansatz:

Mir ist bei dem Folgenden etwas unwohl. Bitte mit äußerster Vorsicht
genießen:

1) Das Skript enthält einen verdeckten sudo-Aufruf.
2) a) Es wird mit root-Rechten eine Datei in ein Verzeichnis
      geschrieben, das unter der Kontrolle des aufrufenden Benutzers
      steht.
   b) Die Datei soll nachher von ebendiesem Benutzer gelesen und
      gelöscht werden.

Der Wrapper sieht dann so aus:
#v+
# mc-sudo-wrapper.sh
MC_USER=`id | sed 's/[^(]*(//;s/).*//'`
MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"

sudo /usr/bin/mc -P "$MC_PWD_FILE" "$@"

# Datei für aufrufenden Benutzer lesbar machen
sudo chown -- "$MC_USER" "$MC_PWD_FILE"

if test -r "$MC_PWD_FILE"; then
	MC_PWD="`cat "$MC_PWD_FILE"`"
	if test -n "$MC_PWD" && test -d "$MC_PWD"; then
		cd "$MC_PWD"
	fi
	unset MC_PWD
fi

rm -f "$MC_PWD_FILE"
unset MC_PWD_FILE
unset MC_USER
#v-

Ich habe im mc-Aufruf das sudo ergänzt und das "sudo chown ..."
hinzugefügt, damit die pwd-Datei in der Abfrage gelesen werden kann.
(mc erstellt die Datei mit Berechtigungen 0600)

Aufgerufen werden muss das dann ebenso über einen Alias, also z.B.

#v+
# sudo mc
alias smc='. ~/scripts/mc-sudo-wrapper.sh'
#v-

in die ~/.bashrc des Benutzers packen. (Pfade selbständig anpassen!)

>> Unter openSUSE ging das einfacher, da gab's aber auch ein Passwort für 
>> root. Das ist im Sicherheitskonzept unter Ubuntu/Mint/LMDE eben anders.
>
> Das ist halt eine der vielen Spezialitäten von Debian, die von den davon
> abgeleiteten Distributionen meistens einfach übernommen werden. Entweder
> arrangiert man sich damit, oder man läßt's halt...

Unsinn. Der Debian-Installer fragt (zumindest in Expert-Mode) nach, ob
man einen echten Root-Account will. Die Derivate können natürlich
machen, was sie wollen.

Lutz

[toc] | [prev] | [next] | [standalone]

#111047

Ich schrieb:

> Mir ist bei dem Folgenden etwas unwohl. Bitte mit äußerster Vorsicht
> genießen:
>
> 1) Das Skript enthält einen verdeckten sudo-Aufruf.
> 2) a) Es wird mit root-Rechten eine Datei in ein Verzeichnis
>       geschrieben, das unter der Kontrolle des aufrufenden Benutzers
>       steht.
>    b) Die Datei soll nachher von ebendiesem Benutzer gelesen und
>       gelöscht werden.

Ich möchte an dieser Stelle noch nachschieben, dass das ganze
Unterfangen - mc mittels sudo ausführen - natürlich jeglichen
möglichen Sicherheisgewinn durch sudo ad absurdum führt!

Lutz

[toc] | [prev] | [next] | [standalone]

#111072

Lutz Falke <lutzfalke@gmx.de>:

>Nein das funktioniert so nicht. Die Verzeichniswechselei wird durch 
>den "sudo"-Befehl unterbrochen, weil da noch mindestens ein 
>zusätzlicher Prozess beteiligt ist. tlrd; Das "sudo" muss in den 
>Wrapper.
>
>Erklärender Einschub: 
>

[zustimmend gelöscht]  


>Lösungsansatz:
>
>Mir ist bei dem Folgenden etwas unwohl. 
>

Mir sogar sehr.  Mir ist generell dabei unwohl, dass «mc» eine 
(mit der Option «-P» angegebene) Datei beschreibt, die der ihn 
aufrufende Shell anschließend abarbeiten soll.  Das ginge 
prinzipiell besser ohne Datei: 

[…]

Die klassische Methode, den Aufrufer‐Shell zu veranlassen, vom 
aufgerufenen Kommando eine Zeichenkette entgegenzunehmen (hier: 
vom Midnight‐Commander das neue Arbeitsverzeichnis), ist, das 
aufgerufene Kommando die Zeichenkette auf standard output ausgeben 
zu lassen und dann als Wrapper eine Shell‐Funktion oder ein 
Shell‐Alias zu verwenden, die bzw. das sich des command 
substitutions bedient: 

Man definiert sich die Funktionen «mc» und «sudo_mc» wie folgt:  


   mc()
   {
     set -- \
       "$(
         command -- mc -P /dev/fd/3 "$@" 3>&1 1>&4 4>&- &&
         printf '%s' '/' 4>&-
       )" 4>&1 &&
     set -- "${1%?}" &&
     ${1:+:} false &&
     case "$1" in
       (-) cd -P -- ./- ;;
       (*) CDPATH= cd -P -- "$dir" ;;
     esac
   }

   sudo_mc()
   {
     set -- \
       "$(
         sudo -C 4 -i bash -c -- \
           '
             command -- mc -P /dev/fd/3 "$@" 3>&1 1>&4 4>&- |
             cat 4>&-
           ' \
           bash &&
         printf '%s' '/' 4>&-
       )" 4>&1 &&
     ${1:+:} false &&
     case "$1" in
       (-) cd -P -- ./- ;;
       (*) CDPATH= cd -P -- "$dir" ;;
     esac
   }

Der Witz dabei:  Weil hier keine (extra angelegte) temporäre Datei 
im Spiel ist – der Shell legt bei command substitution vermutlich 
selber eine an, räumt sie aber auch selber ab –, gibt es, auch 
wenn der Midnight‐Commander unter «root» läuft, keinen Ärger mit 
für den Nicht‐Root‐Benutzer nicht lesbaren, «root» gehörenden 
Dateien. 

Damit «sudo_mc» aber funktioniert, muss wegen der 
Sudo‐Aufruf‐Option «-C» die Sudoers‐Option «closefrom_override» in 
der Sudo‐Konfigurationsdatei («sudoers») eingeschaltet sein. 

Die Funktionsdefinitionen können in die Datei 
«/usr/lib/mc/mc-wrapper.sh» eingetragen werden.  Deren Inhalt kann 
man dann mit dem Kommando

   . /usr/lib/mc/mc-wrapper.sh

in der Datei «~/.bashrc» dem Shell bekannt machen.  


Ob das mit dem «tcsh» auch zu machen ist, weiß ich nicht:  Das 
kenne ich zu wenig, um das beurteilen zu können. 

[toc] | [prev] | [next] | [standalone]

#111079

Lutz Falke <lutzfalke@gmx.de>:

>Nein das funktioniert so nicht. Die Verzeichniswechselei wird durch 
>den "sudo"-Befehl unterbrochen, weil da noch mindestens ein 
>zusätzlicher Prozess beteiligt ist. tlrd; Das "sudo" muss in den 
>Wrapper.
>
>Erklärender Einschub: 
>

[zustimmend gelöscht]  


>Lösungsansatz:
>
>Mir ist bei dem Folgenden etwas unwohl. 
>

Mir sogar sehr.  Mir ist generell dabei unwohl, dass «mc» eine 
(mit der Option «-P» angegebene) Datei beschreibt, die der ihn 
aufrufende Shell anschließend abarbeiten soll.  Das ginge 
prinzipiell besser ohne Datei: 

[…]

Die klassische Methode, den Aufrufer‐Shell zu veranlassen, vom 
aufgerufenen Kommando eine Zeichenkette entgegenzunehmen (hier: 
vom Midnight‐Commander das neue Arbeitsverzeichnis), ist, das 
aufgerufene Kommando die Zeichenkette auf standard output ausgeben 
zu lassen und dann als Wrapper eine Shell‐Funktion oder ein 
Shell‐Alias zu verwenden, die bzw. das sich des command 
substitutions bedient: 

Man definiert sich die Funktionen «mc» und «sudo_mc» wie folgt:  


   mc()
   {
     set -- \
       "$(
         command -- mc -P /dev/fd/4 "$@" 4>&1 1>&3 3>&- &&
         printf '%s' '/' 3>&-
       )" 3>&1 &&
     set -- "${1%?}" &&
     ${1:+:} false &&
     case "$1" in
       (-) cd -P -- ./- ;;
       (*) CDPATH= cd -P -- "$1" ;;
     esac
   }

   sudo_mc()
   {
     set -- \
       "$(
         sudo -C 4 -i bash -c -- \
           '
             CDPATH= cd -- "$PWD" && shift &&
             set -o pipefail &&
             command -- mc -P /dev/fd/4 "$@" 4>&1 1>&3 3>&- |
             cat 3>&-
           ' bash "$PWD" "$@" 3>&3 &&
         printf '%s' '/' 3>&-
       )" 3>&1 &&
     set -- "${1%?}" &&
     ${1:+:} false &&
     case "$1" in
       (-) cd -P -- ./- ;;
       (*) CDPATH= cd -P -- "$1" ;;
     esac
   }

(Supersedes: gegenüber der vorigen Fassung die file descriptors 3
und 4 vertauscht, weitere Fehler behoben.  Dennoch alles noch
ungetestet.) 

Der Witz dabei:  Weil hier keine (extra angelegte) temporäre Datei 
im Spiel ist – der Shell legt bei command substitution 
möglicherweise selber eine an, räumt sie aber auch selber ab –, 
gibt es, auch wenn der Midnight‐Commander unter «root» läuft, 
keinen Ärger mit für den Nicht‐Root‐Benutzer nicht lesbaren, 
«root» gehörenden Dateien. 

Damit «sudo_mc» aber funktioniert, muss wegen der 
Sudo‐Aufruf‐Option «-C» die Sudoers‐Option «closefrom_override» in 
der Sudo‐Konfigurationsdatei («sudoers») eingeschaltet sein. 

Die Funktionsdefinitionen können in die Datei 
«/usr/lib/mc/mc-wrapper.sh» eingetragen werden.  Deren Inhalt kann 
man dann mit dem Kommando

   . /usr/lib/mc/mc-wrapper.sh

in der Datei «~/.bashrc» dem Shell bekannt machen.  


Ob das mit dem «tcsh» auch zu machen ist, weiß ich nicht:  Das 
kenne ich zu wenig, um das beurteilen zu können. 

[toc] | [prev] | [next] | [standalone]

#111219

Helmut Waitzmann:

>   sudo_mc()
>   {
>     set -- \
>       "$(
>         sudo -C 4 -i bash -c -- \
>           '
>             CDPATH= cd -- "$PWD" && shift &&
                            ^
Statt "$PWD" muss das natürlich "$1" heißen.



Friedhelm

[toc] | [prev] | [next] | [standalone]

#111106

Am 14.06.20 um 20:25 schrieb Lutz Falke:
> Sieghard Schicktanz schrieb:
>> Hallo Matthias,
>>
>> Du schriebst am Fri, 12 Jun 2020 23:50:35 +0200:
>>
>>>> Ich les' immer "sudo"-irgendwas und nimmt nicht die root-Einstellungen -
>> ...
>>>> schaltet er für den Aufruf auf das "$HOME" des dafür eingesetzten
>>>> Benutzers, bei einem "root"- Aufruf also das "$HOME" von
>>>> "root" ("/root").
>>>
>>> Geht auch nicht. Ist ja eigentlich auch nur eine Kleinigkeit, die mich
>>> stört:
>>> Unter <Benutzer> bleibt der im MC aktuell gewählte Pfad beim Verlassen
>>> (F10) erhalten, unter 'sudo mc' nicht, sondern er kehrt stets zu dem
>>> Pfad zurück, von dem aus ich ihn aufgerufen habe. Alle anderen
>>> Einstellungen werden artig übernommen.
> 
> Von sudo war im OP noch keine Rede. Zusammen mit sudo funktioniert das
> so nicht. Siehe unten.
> 
>> Ahso. Dann liegt das eher daran, daß mit dem "sudo"-Aufruf die Aliases des
>> Benutzers ungültig werden. Wenn der "mc" beim Aufruf in das zuletzt
>> benutzte Verzeichnis wechseln (!) soll, dann muß er dazu über das schon
>> angesprochene "wrapper"-Skript aufgerufen werden, und das wird mittels des
>> "alias mc='. /usr/share/mc/bin/mc-wrapper.sh'" gesetzt. Du kannst das
>> feststellen, indem Du "sudo bash -c alias mc" eingibst. (Die "bash" muß hier
>> explizit vorgeschaltet weden, weil die "alias"-Einstellungn "ihr gehören",
>> d.h. nur in dieser vorhanden sind.) Wahrscheinlich erfolgt daraufhin gar
>> keine Ausgabe, was heißt, daß für diesen Aufruf kein solches Alias
>> existiert.
> 
> Möglich, das spielt aber keine Rolle.
> 
>> Wenn Du dafür dasselbe Verhalten wie für den Benutzer haben willst, mußt Du
>> die von "sudo" benutzte Shell (wohl "bash") dazu bringen, diesen Alias
>> anzulegen. Dafür gibt's mehreeMöglichkeiten, eine davon wäre, den in Deinem
>> "~/.bashrc" einzutragen, bzw. in dem von "root".
>> Es gibt auch noch die Möglichkeit, das automatisch für alle Benutzer inkl.
>> "root" zu setzen, falls gewünscht. Das muß dann natürlich "root" machen,
>> weil dazu in "/etc/profile.d" ein Eintrag angelegt werden muß. Für die
>> "bash" als Benutzer-Shell muß das ein File mit der Endung ".sh" sein, das
>> dann die obige "alias"-Definition enthält. Ein solches liefert der "mc" in
>> seinem Systemverzeichnis ("/usr/lib/mc" o.ä.) als "mc.sh" schon fertig mit.
> 
> Nein das funktioniert so nicht. Die Verzeichniswechselei wird durch
> den "sudo"-Befehl unterbrochen, weil da noch mindestens ein
> zusätzlicher Prozess beteiligt ist. tlrd; Das "sudo" muss in den
> Wrapper.
> 
> Erklärender Einschub:
> 
> Grob gesagt, ist die Struktur folgendermaßen:
> 1) Die Shell (Elternprozess) startet mc (Kindprozess)
> 
> bzw.
> 
> 2) Die Shell (Großelternprozess) startet sudo (Elternprozess).
>     sudo startet mc (Kindprozess)
> 
> Nun ist es so, dass ein Kindprozess (ausser eventuell durch explizte
> Kommunikation, die hier aber nicht vorgesehen ist) keinen Einfluß auf
> das Arbeitsverzeichnis (current working directory) des Elternprozesses
> hat. Darum der Klimmzug mit dem Wrapper.
> 
> Selbst wenn man im zweiten Fall (mit sudo) dort den Wrapper einbaut,
> bringt das nichts. Dann ändert sich zwar kurzzeitig das
> Arbeitsverzeichnis des sudo-Prozesses, das hat aber keinen Einfluß auf
> die ursprünglich aufrufende Shell.
> 
> Lösungsansatz:
> 
> Mir ist bei dem Folgenden etwas unwohl. Bitte mit äußerster Vorsicht
> genießen:
> 
> 1) Das Skript enthält einen verdeckten sudo-Aufruf.
> 2) a) Es wird mit root-Rechten eine Datei in ein Verzeichnis
>        geschrieben, das unter der Kontrolle des aufrufenden Benutzers
>        steht.
>     b) Die Datei soll nachher von ebendiesem Benutzer gelesen und
>        gelöscht werden.
> 
> Der Wrapper sieht dann so aus:
> #v+
> # mc-sudo-wrapper.sh
> MC_USER=`id | sed 's/[^(]*(//;s/).*//'`
> MC_PWD_FILE="${TMPDIR-/tmp}/mc-$MC_USER/mc.pwd.$$"
> 
> sudo /usr/bin/mc -P "$MC_PWD_FILE" "$@"
> 
> # Datei für aufrufenden Benutzer lesbar machen
> sudo chown -- "$MC_USER" "$MC_PWD_FILE"
> 
> if test -r "$MC_PWD_FILE"; then
> 	MC_PWD="`cat "$MC_PWD_FILE"`"
> 	if test -n "$MC_PWD" && test -d "$MC_PWD"; then
> 		cd "$MC_PWD"
> 	fi
> 	unset MC_PWD
> fi
> 
> rm -f "$MC_PWD_FILE"
> unset MC_PWD_FILE
> unset MC_USER
> #v-
> 
> Ich habe im mc-Aufruf das sudo ergänzt und das "sudo chown ..."
> hinzugefügt, damit die pwd-Datei in der Abfrage gelesen werden kann.
> (mc erstellt die Datei mit Berechtigungen 0600)
> 
> Aufgerufen werden muss das dann ebenso über einen Alias, also z.B.
> 
> #v+
> # sudo mc
> alias smc='. ~/scripts/mc-sudo-wrapper.sh'
> #v-
> 
> in die ~/.bashrc des Benutzers packen. (Pfade selbständig anpassen!)
> 
>>> Unter openSUSE ging das einfacher, da gab's aber auch ein Passwort für
>>> root. Das ist im Sicherheitskonzept unter Ubuntu/Mint/LMDE eben anders.
>>
>> Das ist halt eine der vielen Spezialitäten von Debian, die von den davon
>> abgeleiteten Distributionen meistens einfach übernommen werden. Entweder
>> arrangiert man sich damit, oder man läßt's halt...
> 
> Unsinn. Der Debian-Installer fragt (zumindest in Expert-Mode) nach, ob
> man einen echten Root-Account will. Die Derivate können natürlich
> machen, was sie wollen.

Also da wird mir schier schlecht, ich glaube da gebe ich lieber dem Root 
ein Passwort, als diesen - noch dazu unsicheren - Klimmzug machen zu 
müssen. Bin auch nicht so geübt in der Shell-Programmierung, als das ich 
das wirklich komplett nachvollziehen könnte (obwohl das nicht schwer 
aussieht). Kenne aber einige Befehle nicht (den cryptischen Ausdruck 
hinter sed, unset, usw.).
Deine ursprüngliche, einfachere Wrapper-Lösung (ziemlich am Anfang der 
Diskussion) hatte ich schon probiert, das hatte aber nicht funktioniert.

Wie schon erwähnt, unter openSUSE hatte das früher funktioniert, weil es 
da standardmäßig auch immer ein Passwort für Root gab. Da konnte man 
auch z.B. den Dolphin als Root aufrufen, und der war nicht verkrüppelt 
wie jetzt unter Debian (LMDE 4: keine Icons, keine selbstgewählten 
Schriften).
Manchmal könnte man den echt gut gebrauchen unter Root. Am MC schätze 
ich die pfeilschnelle Navigation, daher mein Wunsch nach Erhalt des 
zuletzt geöffneten Verzeichnisses (wie es unter dem einfachen Benutzer 
ja geht).

M:

[toc] | [prev] | [next] | [standalone]

#110967

Am 12.06.20 um 01:38 schrieb Matthias Gerds:

> sudo mc und Systemverwaltung ist kein Problem, benutzt aber eben die 
> Einstellungen des administrativen Benutzers statt /root/.config/mc/... 
> Man kann sich halt nicht per Root:PW einloggen. 

sudo -i mc

hth,
Lutz

[toc] | [prev] | [next] | [standalone]

#111000

Am Donnerstag, 11.06.2020 23:08 schrieb Gunter Gutzeit:

> > Suche verzweifelt nach der Einstellung, die das im MC (Midnight 
> > Commander) aktuell gewählte Verzeichnis nach dem Verlassen (F10)
> > beibehält. Das finde ich sehr praktisch, weil man mit MC sehr schnell
> > navigieren kann.  
> 
> Optionen > Paneloptionen... > [X] Paneleinstellung autom. speichern

Das zeigt hier noch nicht mal als gewöhnlicher Benutzer Wirkung. Unabhängig
von den Einstellungen startet der mc immer im in $HOME, und nie in dem
zuletzt besuchten Verzeichnis. 

> entspricht:
> 
> ~/.config/mc/panels.ini
> ...
> [Panels]
> ...
> auto_save_setup_panels=true

Bei mir wird der Eintrag in ~/.config/mc/ini angelegt, nicht in panels.ini.

Es funktioniert hier nur unter zusätzlicher Verwendung des von Lutz Falke
erwähnten wrapper-Skripts. Erst dann wird in panels.ini im Abschnitt [Dirs]
die Variable other_dir mit dem zuletzt besuchten Verzeichnis gesichert.
-- 
powered by Arch Linux x86_64 🐧 Kernel: 5.6.15-arch1-1
KDE-Plasma 5.18.5 · KDE-Frameworks 5.70.0 · Qt 5.15.0

[toc] | [prev] | [next] | [standalone]

#111001

Martin Schnitkemper schrieb am Sa 13.06.2020 10:56:15 +0200:

> Bei mir wird der Eintrag in ~/.config/mc/ini angelegt, nicht in panels.ini.

Danke für die Richtigstellung - war in diesem Posting ein Fehler
meinerseits. Zuletzt hatte ich den Pfad aber richtig übertragen:
sudo nano /root/.config/mc/ini
 
> Es funktioniert hier nur unter zusätzlicher Verwendung des von Lutz Falke
> erwähnten wrapper-Skripts. Erst dann wird in panels.ini im Abschnitt [Dirs]
> die Variable other_dir mit dem zuletzt besuchten Verzeichnis gesichert.

Ja - die unterschiedlichen Linux-Distributionen unterscheiden sich an
verschieden Stellen leider sehr erheblich. Das habe ich leidvoll bei
meinem Wechsel von Manjaro nach Debian gemerkt. Hier in Debian brauche
ich dieses Wrapper-Skript nicht.  

-- 
Gunter
https://guntergutzeit.de.cool

[toc] | [prev] | [next] | [standalone]

#111002

Gunter Gutzeit (ich selbst) schrieb am Sa 13.06.2020 12:32:01 +0200:

> Hier in Debian brauche ich dieses Wrapper-Skript nicht.  

Jedenfalls, ohne dass ich es von Hand eingebaut hätte. Ob da ein Debian-
Maintainer eine entsprechende Funktionalität an einer mir unbekannten
Stelle eingebaut hat, entzieht sich meiner Kenntnis.

-- 
Gunter
https://guntergutzeit.de.cool

[toc] | [prev] | [next] | [standalone]

#111009

Am Samstag, 13.06.2020 12:32 schrieb Gunter Gutzeit:

> > Es funktioniert hier nur unter zusätzlicher Verwendung des von Lutz
> > Falke erwähnten wrapper-Skripts. Erst dann wird in panels.ini im
> > Abschnitt [Dirs] die Variable other_dir mit dem zuletzt besuchten
> > Verzeichnis gesichert.  
> 
> Ja - die unterschiedlichen Linux-Distributionen unterscheiden sich an
> verschieden Stellen leider sehr erheblich. Das habe ich leidvoll bei
> meinem Wechsel von Manjaro nach Debian gemerkt. Hier in Debian brauche
> ich dieses Wrapper-Skript nicht.  

Ich muss das vielleicht etwas präzisieren, nachdem ich es mir noch einmal
genauer angesehen habe.  

Die aktive Seite wird immer mit dem Verzeichnis aufgerufen, aus dem der mc
gestartet wurde, und das inaktive Panel enthält das Verzeichnis, aus dem
der mc bei der letzten Session verlassen wurde. Welches das aktive Panel
war, steht in der Variablen "current_is_left". Ist die mit "true" besetzt,
startet der mc mit dem linken Panel, bei "false" mit dem rechten Panel. Und
in "other_dir" steht dann das Verzeichnis, mit dem des inaktiven Panel
geladen wird. 

Das war in sofern bei meinem letzten Versuch etwas verwirrend, weil ich
mich nur im linken Panel befand, und dann in beiden Panels die Inhalten von
$HOME standen. 

Der Wrapper macht auch nichts anderes, als beim Verlassen des mc auf der
Konsole in das Verzeichnis des aktiven Panels zu wechseln. Dadurch lädt
der mc beim erneuten Aufruf das aktive Panel mit dem aktuellen Verzeichnis,
was dann den Eindruck erweckt, der mc würde genau so starten wie man ihn
verlassen hat. 

Das stimmt aber nicht, weil das Verzeichnis des aktiven Panels nirgends
festgehalten wird, was man dann auch sieht, wenn man die Konsole schließt
und neu öffnet; dann ist das aktive Panel nämlich in der Regel wieder mit
$HOME besetzt. 

Haarig wird es, wenn man die Option zur automatischen Speicherung der
Paneloptionen wieder aussetzt. Dann wird nämlich nicht etwa panels.ini
verworfen, sondern die Variablen aus dem Abschnitt [Dirs] weiter
ausgewertet, was dann zur Folge hat, dass das inaktive Panel dauerhaft auf
das letzte Verzeichnis festgenagelt wurde. Das kann unter Umständen ein
angenehmer Seiteneffekt sein, gewöhnlich wird man aber manuell Hand anlegen
müssen, um den Standardzustand wiederherzustellen.  
-- 
powered by Arch Linux x86_64 🐧 Kernel: 5.6.15-arch1-1
KDE-Plasma 5.18.5 · KDE-Frameworks 5.70.0 · Qt 5.15.0

[toc] | [prev] | [next] | [standalone]

#111016

Martin Schnitkemper schrieb am Sa 13.06.2020 18:19:04 +0200:

> Am Samstag, 13.06.2020 12:32 schrieb Gunter Gutzeit:
> 
>>> Es funktioniert hier nur unter zusätzlicher Verwendung des von Lutz
>>> Falke erwähnten wrapper-Skripts. Erst dann wird in panels.ini im
>>> Abschnitt [Dirs] die Variable other_dir mit dem zuletzt besuchten
>>> Verzeichnis gesichert.    
>> 
>> Ja - die unterschiedlichen Linux-Distributionen unterscheiden sich an
>> verschieden Stellen leider sehr erheblich. Das habe ich leidvoll bei
>> meinem Wechsel von Manjaro nach Debian gemerkt. Hier in Debian brauche
>> ich dieses Wrapper-Skript nicht.    
> 
> Ich muss das vielleicht etwas präzisieren, nachdem ich es mir noch einmal
> genauer angesehen habe.  
> 
> Die aktive Seite wird immer mit dem Verzeichnis aufgerufen, aus dem der mc
> gestartet wurde, und das inaktive Panel enthält das Verzeichnis, aus dem
> der mc bei der letzten Session verlassen wurde. Welches das aktive Panel
> war, steht in der Variablen "current_is_left". Ist die mit "true" besetzt,
> startet der mc mit dem linken Panel, bei "false" mit dem rechten Panel. Und
> in "other_dir" steht dann das Verzeichnis, mit dem des inaktiven Panel
> geladen wird. 
> 
> Das war in sofern bei meinem letzten Versuch etwas verwirrend, weil ich
> mich nur im linken Panel befand, und dann in beiden Panels die Inhalten von
> $HOME standen. 
> 
> Der Wrapper macht auch nichts anderes, als beim Verlassen des mc auf der
> Konsole in das Verzeichnis des aktiven Panels zu wechseln. Dadurch lädt
> der mc beim erneuten Aufruf das aktive Panel mit dem aktuellen Verzeichnis,
> was dann den Eindruck erweckt, der mc würde genau so starten wie man ihn
> verlassen hat. 

interessant:
Warum der MC bei mir mit Debian ohne Klimmzüge genau das macht, was er
soll und bei mir alles ohne Wrapper läuft, so wie es soll, verstehe ich
ja auch nicht :-)
 
> Das stimmt aber nicht, weil das Verzeichnis des aktiven Panels nirgends
> festgehalten wird, [...]

bedenke:
für den User-Modus: ~/.local/share/mc/history
für den Root-Modus: /root/.local/share/mc/history

Da stehen auch noch ein paar wichtige Sachen drin und im Zusammenhang
mit current_is_left=true bzw =false kann der MC schon seine Infos laden,
die er braucht, um korrekt zu funktionieren.

> [...] was man dann auch sieht, wenn man die Konsole schließt
> und neu öffnet; dann ist das aktive Panel nämlich in der Regel wieder mit
> $HOME besetzt. 
> 
> Haarig wird es, wenn man die Option zur automatischen Speicherung der
> Paneloptionen wieder aussetzt. Dann wird nämlich nicht etwa panels.ini
> verworfen, sondern die Variablen aus dem Abschnitt [Dirs] weiter
> ausgewertet, was dann zur Folge hat, dass das inaktive Panel dauerhaft auf
> das letzte Verzeichnis festgenagelt wurde. Das kann unter Umständen ein
> angenehmer Seiteneffekt sein, gewöhnlich wird man aber manuell Hand anlegen
> müssen, um den Standardzustand wiederherzustellen.  

mein Nutzungsverhalten:
Ich hatte die hier in Rede stehenden Optionen [X] Paneleinstellung
autom. speichern, sowohl im User- als auch Root-Modus immer deaktiviert,
weil ich damals noch zu Puppy-/Manjaro-Zeiten immer in den selben
Verzeichnissen starten wollte. Das ist eigentlich auch jetzt noch so.

Das heißt, bei der Vielzahl meiner Mc-Aufrufe bringt es tatsächlich
keinen Rationalisierungsgewinn, wenn ich immer mit den letzten
Verzeichnissen starte. Inzwischen ist es mir aber auch egal, da ich
den Mc darüber hinaus fast immer kontextbezogen und skriptgesteuert mit
den Verzeichnissen starte, die ich für die jeweilige Arbeitssituation
brauche. Da wo sich eh nix festschreiben lässt - überwiegend während
meiner ssh-Sitzungen - lade ich alte Verzeichnisse schnell per Mausklick
über die History = Chronik-Button nach.

Da ich im Zuge dieses Threads aber überlegt habe, dass mir dieses
Feature aber auch nicht schadet, habe ich es jetzt auf allen meinen
Systemen aktiviert. Es könnte nämlich dann nützlich sein, wenn man
unstruktiert arbeitet, zum Beispiel jetzt, wo ich mir ein AntiX-Frugal
mit Installationsskripten from Scratch bastele und man ohnehin Vieles
über die Konsole eingeben muss. 

Ich musste meine Mc-Konfiguration jetzt sowieso aufräumen.   

-- 
Gunter
https://guntergutzeit.de.cool

[toc] | [prev] | [next] | [standalone]

#111031

Am Samstag, 13.06.2020 21:04 schrieb Gunter Gutzeit:

> interessant:
> Warum der MC bei mir mit Debian ohne Klimmzüge genau das macht, was er
> soll und bei mir alles ohne Wrapper läuft, so wie es soll, verstehe ich
> ja auch nicht :-)

Ich auch nicht... als ich noch bei Debian war, startete der mc immer mit
dem letzten Verzeichnis. Ich habe mir aber nie Gedanken darüber gemacht,
wie das realisiert wurde, weil ich bis dahin dachte, dass sei das
Standardverhalten des mc.

Erst nach Wechsel zu Arch war es mit damit vorbei.

Wie Debian da trickst, habe ich aber auch noch nicht herausgefunden.  
-- 
powered by Arch Linux x86_64 🐧 Kernel: 5.7.2-arch1-1
KDE-Plasma 5.19.0 · KDE-Frameworks 5.70.0 · Qt 5.15.0

[toc] | [prev] | [next] | [standalone]

#111034

Gunter Gutzeit <gunter.gutzeit@arcor.de>:

>bedenke:
>für den User-Modus: ~/.local/share/mc/history
>für den Root-Modus: /root/.local/share/mc/history

Um es nochmal deutlich zu machen:  Sowohl für User als auch für
Root ist es immer «~/.local/share/mc/history», wobei der Witz
dabei ist, dass die Zeichenfolge «~/» für «"$HOME"/» steht, also
den Inhalt der Umgebungsvariablen «HOME» verwendet. 

Damit das bei Root richtig funktioniert, muss man demnach dafür
sorgen, dass die Umgebungsvariable «HOME» den richtigen Inhalt, im
Beispiel oben bei «root» also «/root», hat. 

Das hat sie dann, wenn man bei «su» im Aufruf die Optionen
«--login» oder «-l» oder als ersten Nicht‐Optionen‐Parameter «-»
angibt, oder, wenn man bei «sudo» im Aufruf die Optionen «-H»,
«-i» oder «--login» oder in der Konfigurationsdatei «sudoers» das
Konfigurationselement «always_set_home» verwendet. 

[toc] | [prev] | [next] | [standalone]

#111019

Am 13.06.20 um 10:56 schrieb Martin Schnitkemper:
> Am Donnerstag, 11.06.2020 23:08 schrieb Gunter Gutzeit:
> 
>>> Suche verzweifelt nach der Einstellung, die das im MC (Midnight
>>> Commander) aktuell gewählte Verzeichnis nach dem Verlassen (F10)
>>> beibehält. Das finde ich sehr praktisch, weil man mit MC sehr schnell
>>> navigieren kann.
>>
>> Optionen > Paneloptionen... > [X] Paneleinstellung autom. speichern
> 
> Das zeigt hier noch nicht mal als gewöhnlicher Benutzer Wirkung. Unabhängig
> von den Einstellungen startet der mc immer im in $HOME, und nie in dem
> zuletzt besuchten Verzeichnis.

Das ist nur ein kleiner Fehler. Du musst 'Einstellungen speichern' nur 
einmal per Hand machen, dann merkt er sich's im Folgenden.

>> entspricht:
>>
>> ~/.config/mc/panels.ini
>> ...
>> [Panels]
>> ...
>> auto_save_setup_panels=true
> 
> Bei mir wird der Eintrag in ~/.config/mc/ini angelegt, nicht in panels.ini.
> 
> Es funktioniert hier nur unter zusätzlicher Verwendung des von Lutz Falke
> erwähnten wrapper-Skripts. Erst dann wird in panels.ini im Abschnitt [Dirs]
> die Variable other_dir mit dem zuletzt besuchten Verzeichnis gesichert.
> 

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | de.comp.os.unix.linux.misc

csiph-web