Re: script ocaml utilisant module Unix
Le 03/06/2024 à 11:31, Basile Starynkevitch a écrit : Bonjour la liste Sur mon système Debian Testing j'ai % /usr/bin/ocaml --version The OCaml toplevel, version 4.14.1 Sans utiliser opam je voudrais améliorer dans https://github.com/RefPerSys/RefPerSys/commit/dbf79c52dafd6b26d028c407c7339d1645ad8479 le script Create-RefPerSys.ocaml pour que le module Unix soit chargé (et seules les distributions Linux m'intéressent) Comment faire? Cordialement Bonjour Avertissement: je ne connais strictement rien à Ocalm bien qu'il semble être possible d'installer Ocalm sans Opam (le gestionnaire de paquets sources d'Ocalm), ça semble aussi amener des difficultés ou dysfonctionnements d'après les entrefilets trouvés sur internet. En tout cas l'installation minimale d'Ocalm telle que recommandée par le site Ocalm.org implique l'installation d'Opam comme étape préalable: https://ocaml.org/docs/installing-ocaml Les paquets sources Ocaml relatifs à Unix sont là: https://ocaml.org/packages/search?q=unix peut-être regarder du côté de core-unix et base-unix (simple supposition, ce n'est peut-être pas ça) La doc sur les modules (si il s'agit bien de modules au sens Ocalm du terme) et la façon de les utiliser est là, tu trouveras peut-être (je n'ai pas lu) un indice sur comment faire sans Opam: https://ocaml.org/docs/modules
script ocaml utilisant module Unix
Bonjour la liste Sur mon système Debian Testing j'ai % /usr/bin/ocaml --version The OCaml toplevel, version 4.14.1 Sans utiliser opam je voudrais améliorer dans https://github.com/RefPerSys/RefPerSys/commit/dbf79c52dafd6b26d028c407c7339d1645ad8479 le script Create-RefPerSys.ocaml pour que le module Unix soit chargé (et seules les distributions Linux m'intéressent) Comment faire? Cordialement -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 8 rue de la Faïencerie, 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ -gives my mobile number +33 6 8501 See/voir: https://github.com/RefPerSys/RefPerSys
Re: How to run automatically a script as soon root login
On Tue, May 14, 2024 at 02:51:17PM +0200, Mario Marietto wrote: > I've installed the Cloudflare gateway on Debian as a vm because I can't do > it directly in FreeBSD. But I want to be covered even when I use FreeBSD. > The script that I wrote forward the Cloudflare "VPN" from Debian to > FreeBSD,so from outside my IP will be cloudFlared. Disclaimer: I know nothing about Cloudflare. So you wrote a bash script. I will assume this script does what you want it to. You type its name to run it, or you have it set up to run at boot time, or you have it set up to run at login time, or via a cron job, or via a DHCP dhclient enter/exit hook Where does the GOTO come in? Do you think your script does something internally which mimics a GOTO in some way? Or that it *should* do that? Why would you need a GOTO to do whatever networking configuration steps the script does? Lacking any knowledge of Cloudflare, I'm imagining that the script simply performs a sequence of commands, in a linear order, without any branching or looping or jumping around.
Re: How to run automatically a script as soon root login
I've installed the Cloudflare gateway on Debian as a vm because I can't do it directly in FreeBSD. But I want to be covered even when I use FreeBSD. The script that I wrote forward the Cloudflare "VPN" from Debian to FreeBSD,so from outside my IP will be cloudFlared. On Tue, May 14, 2024 at 1:16 PM Greg Wooledge wrote: > On Tue, May 14, 2024 at 01:10:05PM +0200, Mario Marietto wrote: > > Your answer does not help me to understand how to use a "structured > > programming / if , while, for, functions" for the specific task that I > want > > to achieve. > > What task is that? > > -- Mario.
Re: How to run automatically a script as soon root login
On Tue, May 14, 2024 at 01:10:05PM +0200, Mario Marietto wrote: > Your answer does not help me to understand how to use a "structured > programming / if , while, for, functions" for the specific task that I want > to achieve. What task is that?
Re: How to run automatically a script as soon root login
Your answer does not help me to understand how to use a "structured programming / if , while, for, functions" for the specific task that I want to achieve. I failed using "your" lovely structured programming and that's the reason why I'm asking for some hint to understand why and how I can use it. Your answer puts the finger on the spot and isn't helpful, also because it says things that I already knew. On Tue, May 14, 2024 at 1:03 PM Greg Wooledge wrote: > On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote: > > Nobody can show a different way,a modern way, for creating my script ? > Why > > did I feel so comfortable by recreating the 1960s GOTO statement in Bash > ? > > I have absolutely no clue what you're trying to do or why you're trying > to do it, but I *promise* you, whatever you think you're doing, you > have NOT recreated a GOTO statement in bash. > > You showed a function. Functions can be called. This is NOT the same > as issuing a GOTO command, because once the function returns, control > flow resumes from the point where it was called. > > Bash (and sh, on which bash is based) explicitly chose not to have a GOTO > statement in its language. The authors chose instead to use the control > primitives that are collectively known as "structured programming" > (if, while, for, functions). > > -- Mario.
Re: How to run automatically a script as soon root login
On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote: > Nobody can show a different way,a modern way, for creating my script ? Why > did I feel so comfortable by recreating the 1960s GOTO statement in Bash ? I have absolutely no clue what you're trying to do or why you're trying to do it, but I *promise* you, whatever you think you're doing, you have NOT recreated a GOTO statement in bash. You showed a function. Functions can be called. This is NOT the same as issuing a GOTO command, because once the function returns, control flow resumes from the point where it was called. Bash (and sh, on which bash is based) explicitly chose not to have a GOTO statement in its language. The authors chose instead to use the control primitives that are collectively known as "structured programming" (if, while, for, functions).
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
On Tue, May 14, 2024 at 04:54:26PM +0800, Bret Busby wrote: > > Wasn't sudo echo the name of a pop group? > > :) If it wasn't it should've been one. Cheers -- t signature.asc Description: PGP signature
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
Wasn't sudo echo the name of a pop group? :) Bret Busby Armadale Western Australia (UTC+0800) .
Re: How to run automatically a script as soon root login
On Tue, May 14, 2024 at 08:09:18AM +0200, Mario Marietto wrote: > Nobody can show a different way,a modern way, for creating my script ? Why > did I feel so comfortable by recreating the 1960s GOTO statement in Bash ? I think your style is too alien to most of the people here to make them feel their time is worth trying to wrap their heads around it (I just got a rough feeling on how it works, asked myself "Why?" and went on). You'll have to go it alone if you chose such an idiosyncratic style, it seems. Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
Nobody can show a different way,a modern way, for creating my script ? Why
did I feel so comfortable by recreating the 1960s GOTO statement in Bash ?
On Mon, May 13, 2024 at 6:30 PM Will Mengarini wrote:
> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Bash*?!
>
> * Mario Marietto [24-05/13=Mo 13:37 +0200]:
> > function jumpto
> > {
> > label=$1
> > cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> > eval "$cmd"
> > exit
> > }
>
> Anyway, Marietto, you've got two typi:
>
> > mid :
> That should be "mid:".
>
> > jump foo
> That should be "jumpto foo".
>
> Once you've got your root-login script working, I hope you
> move on to implementing a complete open-source PL/I compiler.
>
--
Mario.
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
On Mon, May 13, 2024 at 08:37:16PM +0200, Erwan David wrote: > Le 13/05/2024 à 19:45, Stefan Monnier a écrit : [...] > > % sudo zsh -l > > # echo 1 > /proc/sys/net/ipv4/ip_forward > > # ^D > > logout > > % > > > > > > > > > > Stefan > > > > > sudo -i will do the job instead of sudo zsh -l ...provided Stefan's shell in /etc/passwd is set to zsh, that is :) Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
yeah at the beginning i used xorg + xfce but then i realized that i did not need them,so the context became the textual mode. Il lun 13 mag 2024, 21:52 David Wright ha scritto: > On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote: > > On Mon, May 13, 2024 at 9:05 PM Greg Wooledge wrote: > > > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > > > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > > > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > > > > .profile > > > > > > > > Sorry, dumb question: Depending of the shell, the user is using > (let's > > > say, he > > > > will use bash), can the script not be added into ~/.bashrc? > > > > > > The context has been snipped out. The context for this was "OP is > trying > > > to run a command when root logs in". The method of login was not > stated. > > > First responder said ".profile works for every method of login". I > said > > > that this is incorrect: it doesn't work for many GUI login setups. > > > > > > In those same GUI login setups, .bashrc is *also* not read when the > > > user logs in. None of the shell startup files are read at all. > > > > > > All of this is a tangent to the actual problem, though. > > > > > > > If yes, second dumb question: Coiuld it be ANY script or command? > > > > (also running as non-rootuser, like adding "runuser -u myuser > > > > command_whatever"). > > > > > > We're several layers deep into an X-Y problem here. The *actual* > problem > > > is that the system's networking configuration is not correct/complete. > > > > > > The *workaround* is that the OP is logging in and running commands to > > > change the networking configuration temporarily. > > > > > > The question resulting from the workaround (the Y in the X-Y) was "How > > > can I automate these commands that I keep having to type?" > > > > > > The proper question should have been "How can I fix my system's > networking > > > configuration permanently?" > > > > > ---> The context has been snipped out > > > > nope. Read well what I said on my first post : > > > > > > *[Forgot to say that I switched boot target to text with this command :* > > > > *sudo systemctl set-default multi-user.target]* > > > > What does this mean for you ? > > To me, it means just one more change while trying to get your > networking to work. Your OP finished with "It does not work and anyway > it does not seem to be what I want..." and "I suspect that the > solution is easier than what I'm trying to do...". Again, to me, > that suggests that after settling on a better, permanent solution > to your problem, you would roll back the other changes that you > made along the way. > > > The context is that I was not using any > > desktop manager. > > My understanding of this statement is that "the context" is what > is described in your OP. As you said you "switched boot target to > text", I would assume you originally had a different target, likely > a DM, and that you might revert back to it after solving the problem. > > Cheers, > David. > >
Re: How to run automatically a script as soon root login
On Mon 13 May 2024 at 21:18:30 (+0200), Mario Marietto wrote: > On Mon, May 13, 2024 at 9:05 PM Greg Wooledge wrote: > > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > > > .profile > > > > > > Sorry, dumb question: Depending of the shell, the user is using (let's > > say, he > > > will use bash), can the script not be added into ~/.bashrc? > > > > The context has been snipped out. The context for this was "OP is trying > > to run a command when root logs in". The method of login was not stated. > > First responder said ".profile works for every method of login". I said > > that this is incorrect: it doesn't work for many GUI login setups. > > > > In those same GUI login setups, .bashrc is *also* not read when the > > user logs in. None of the shell startup files are read at all. > > > > All of this is a tangent to the actual problem, though. > > > > > If yes, second dumb question: Coiuld it be ANY script or command? > > > (also running as non-rootuser, like adding "runuser -u myuser > > > command_whatever"). > > > > We're several layers deep into an X-Y problem here. The *actual* problem > > is that the system's networking configuration is not correct/complete. > > > > The *workaround* is that the OP is logging in and running commands to > > change the networking configuration temporarily. > > > > The question resulting from the workaround (the Y in the X-Y) was "How > > can I automate these commands that I keep having to type?" > > > > The proper question should have been "How can I fix my system's networking > > configuration permanently?" > > > ---> The context has been snipped out > > nope. Read well what I said on my first post : > > > *[Forgot to say that I switched boot target to text with this command :* > > *sudo systemctl set-default multi-user.target]* > > What does this mean for you ? To me, it means just one more change while trying to get your networking to work. Your OP finished with "It does not work and anyway it does not seem to be what I want..." and "I suspect that the solution is easier than what I'm trying to do...". Again, to me, that suggests that after settling on a better, permanent solution to your problem, you would roll back the other changes that you made along the way. > The context is that I was not using any > desktop manager. My understanding of this statement is that "the context" is what is described in your OP. As you said you "switched boot target to text", I would assume you originally had a different target, likely a DM, and that you might revert back to it after solving the problem. Cheers, David.
Re: How to run automatically a script as soon root login
---> The context has been snipped out nope. Read well what I said on my first post : *[Forgot to say that I switched boot target to text with this command :* *sudo systemctl set-default multi-user.target]* What does this mean for you ? The context is that I was not using any desktop manager. On Mon, May 13, 2024 at 9:05 PM Greg Wooledge wrote: > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > > .profile > > > > Sorry, dumb question: Depending of the shell, the user is using (let's > say, he > > will use bash), can the script not be added into ~/.bashrc? > > The context has been snipped out. The context for this was "OP is trying > to run a command when root logs in". The method of login was not stated. > First responder said ".profile works for every method of login". I said > that this is incorrect: it doesn't work for many GUI login setups. > > In those same GUI login setups, .bashrc is *also* not read when the > user logs in. None of the shell startup files are read at all. > > All of this is a tangent to the actual problem, though. > > > If yes, second dumb question: Coiuld it be ANY script or command? > > (also running as non-rootuser, like adding "runuser -u myuser > > command_whatever"). > > We're several layers deep into an X-Y problem here. The *actual* problem > is that the system's networking configuration is not correct/complete. > > The *workaround* is that the OP is logging in and running commands to > change the networking configuration temporarily. > > The question resulting from the workaround (the Y in the X-Y) was "How > can I automate these commands that I keep having to type?" > > The proper question should have been "How can I fix my system's networking > configuration permanently?" > > -- Mario.
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > .profile > > Sorry, dumb question: Depending of the shell, the user is using (let's say, > he > will use bash), can the script not be added into ~/.bashrc? The context has been snipped out. The context for this was "OP is trying to run a command when root logs in". The method of login was not stated. First responder said ".profile works for every method of login". I said that this is incorrect: it doesn't work for many GUI login setups. In those same GUI login setups, .bashrc is *also* not read when the user logs in. None of the shell startup files are read at all. All of this is a tangent to the actual problem, though. > If yes, second dumb question: Coiuld it be ANY script or command? > (also running as non-rootuser, like adding "runuser -u myuser > command_whatever"). We're several layers deep into an X-Y problem here. The *actual* problem is that the system's networking configuration is not correct/complete. The *workaround* is that the OP is logging in and running commands to change the networking configuration temporarily. The question resulting from the workaround (the Y in the X-Y) was "How can I automate these commands that I keep having to type?" The proper question should have been "How can I fix my system's networking configuration permanently?"
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
Le 13/05/2024 à 19:45, Stefan Monnier a écrit : $ su - Password: # echo 1 > /proc/sys/net/ipv4/ip_forward # ^D logout $ I don't need no stinkin' sudo :-) And if you only have `sudo`, but not the root password, of course: % sudo zsh -l # echo 1 > /proc/sys/net/ipv4/ip_forward # ^D logout % Stefan sudo -i will do the job instead of sudo zsh -l
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
On Mon, May 13, 2024 at 01:45:40PM -0400, Stefan Monnier wrote: > > $ su - > > Password: > > # echo 1 > /proc/sys/net/ipv4/ip_forward > > # ^D > > logout > > $ > > > > I don't need no stinkin' sudo :-) > > And if you only have `sudo`, but not the root password, of course: > > % sudo zsh -l > # echo 1 > /proc/sys/net/ipv4/ip_forward > # ^D > logout > % Or just "sudo -s", which will invoke "your" favourite shell. Or "sudo -i", which will do roughly the same (-s looks first at $SHELL, then at passwd, -i looks at passwd and invokes a login shell). > I always forget how my fave shell is spelt ;-) Cheers -- t signature.asc Description: PGP signature
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
> $ su - > Password: > # echo 1 > /proc/sys/net/ipv4/ip_forward > # ^D > logout > $ > > I don't need no stinkin' sudo :-) And if you only have `sudo`, but not the root password, of course: % sudo zsh -l # echo 1 > /proc/sys/net/ipv4/ip_forward # ^D logout % Stefan
Re: sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
On 5/13/24 18:52, to...@tuxteam.de wrote: Now share your ideas :-) $ su - Password: # echo 1 > /proc/sys/net/ipv4/ip_forward # ^D logout $ I don't need no stinkin' sudo :-) regards, chris
Re: How to run automatically a script as soon root login
>> If yes, second dumb question: Coiuld it be ANY script or command? >> (also running as non-rootuser, like adding "runuser -u myuser >> command_whatever"). >Root can do this, yes. Or to be more precise, .bashrc (and any file that's read from it like .bash_aliases) can run anything the bash CLI can run with the same privileges. Of course, anything requiring user input like entering passwords won't work. The same is true for .profile, but with the twist that depending on which shell is reading it, other syntaxes may be possible/required, while .bashrc and similarly named files are pretty much bash-exclusive. So as long as it's something that should run upon login, like setting user-wide environment variables. > Sorry, dumb question: Depending of the shell, the user is using (let's say, he will use bash), can the script not be added into ~/.bashrc? .profile is simply more universal. E.g. I'm mounting cloud storage drives through rclone. Since I put the command into .profile, it won't just be run when I log in to the bash shell, but also when I log in to Gnome. I don't think that would be possible with .bashrc. Best Richard Am Mo., 13. Mai 2024 um 18:34 Uhr schrieb : > On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > > .profile > > > > Sorry, dumb question: Depending of the shell, the user is using (let's > say, he > > will use bash), can the script not be added into ~/.bashrc? > > Yes. Consult your shell's manual. And it will also depend on whether > it is considered to be a "login shell". And on a couple of other > factors. > > > If yes, second dumb question: Coiuld it be ANY script or command? > > (also running as non-rootuser, like adding "runuser -u myuser > > command_whatever"). > > Root can do this, yes. > > Cheers > -- > t >
Re: How to run automatically a script as soon root login
I think I have found my way,adding this line to /etc/sudoers : marietto ALL=(ALL) NOPASSWD: /usr/bin/iptables and on the warp script : sudo /usr/bin/iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE On Mon, May 13, 2024 at 3:20 PM wrote: > On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote: > > On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote: > > > >> sudo xterm -e "echo 1 > hello" > > > > > Yes, but why did it allow me to delete the file? I was not root > > > then. Try it. > > > > Because you have write permission on the *directory* that the file is in. > > > > Removing (unlinking) a file is an operation that modifies a directory, > > not the file itself. You don't need write permission on the file. Just > > the directory. > > Unless the directory has the sticky bit set (e.g. /tmp). > > (For completeness: I know you know that). > > Cheers > -- > t > -- Mario.
sudo echo 1 > /proc/sys/net/ipv4/ip_forward [was: How to run automatically a script as soon root login]
Since this happens so often, I'm trying to offer a recap. As others have noted, the above sudo echo 1 > /proc/sys/net/ipv4/ip_forward won't work, since it runs echo under sudo, but the file opening (that pesky ">") happens in your shell, which is probably running unprivileged (otherwise, what do you need the sudo for, anyway?) Others have rightfully noticed that, in this case, sysctl possibly is the more appropriate tool for the job. Barring that -- what is to do? One solution put forward was to wrap a whole shell in the sudo: sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" Of course, you can (gasp!) wrap a whole xterm which invokes a shell (why not go the full thing and wrap LibreOffice Calc? It surely has a shell escape hidden somewhere ;-) Another solution is to find a program which would be willing to open a named file for you and sudo that one. A common choice would be tee (which in this case has the side effect of dumping the desired output *also* to stdout: echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward (also outputs 1 to stdout). Less common, but my personal favourite is dd, which is free of that side effect (it's harmless enough when it's just an "1", but if longer data is involved...): echo 1 | sudo dd of=/proc/sys/net/ipv4/ip_forward (note that dd's default if is stdin). Now share your ideas :-) Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
Nobody has yet applauded this glorious implementation
of the 1960s GOTO statement in *Bash*?!
* Mario Marietto [24-05/13=Mo 13:37 +0200]:
> function jumpto
> {
> label=$1
> cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> eval "$cmd"
> exit
> }
Anyway, Marietto, you've got two typi:
> mid :
That should be "mid:".
> jump foo
That should be "jumpto foo".
Once you've got your root-login script working, I hope you
move on to implementing a complete open-source PL/I compiler.
Re: How to run automatically a script as soon root login
Mario Marietto writes: > There is still a problem. If I login automatically as user and inside > the script I do this : > > sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE > > it asks me for the password (don't know why it didn't before) but I > can't issue a password,because the script inside the vm should work > automatically and should be hidden between the FreeBSD processes. > Why does it need to be executed at login? Maybe you could get root's crontab to execute it. A script could detect when a user is logged in.
Re: How to run automatically a script as soon root login
I don't have those typos in the code. The typo has been to copy the content
of the script by hand on the email message.
On Mon, May 13, 2024 at 6:30 PM Will Mengarini wrote:
> Nobody has yet applauded this glorious implementation
> of the 1960s GOTO statement in *Bash*?!
>
> * Mario Marietto [24-05/13=Mo 13:37 +0200]:
> > function jumpto
> > {
> > label=$1
> > cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> > eval "$cmd"
> > exit
> > }
>
> Anyway, Marietto, you've got two typi:
>
> > mid :
> That should be "mid:".
>
> > jump foo
> That should be "jumpto foo".
>
> Once you've got your root-login script working, I hope you
> move on to implementing a complete open-source PL/I compiler.
>
--
Mario.
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 06:06:37PM +0200, Hans wrote: > Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > > .profile > > Sorry, dumb question: Depending of the shell, the user is using (let's say, > he > will use bash), can the script not be added into ~/.bashrc? Yes. Consult your shell's manual. And it will also depend on whether it is considered to be a "login shell". And on a couple of other factors. > If yes, second dumb question: Coiuld it be ANY script or command? > (also running as non-rootuser, like adding "runuser -u myuser > command_whatever"). Root can do this, yes. Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
Am Montag, 13. Mai 2024, 13:24:17 CEST schrieb Greg Wooledge: > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > .profile Sorry, dumb question: Depending of the shell, the user is using (let's say, he will use bash), can the script not be added into ~/.bashrc? If yes, second dumb question: Coiuld it be ANY script or command? (also running as non-rootuser, like adding "runuser -u myuser command_whatever"). Just some thoughts Best Hans
Re: How to run automatically a script as soon root login
[image: Istantanea_2024-05-13_17-37-39.png] Can someone explain to me why user "marietto" can't execute the command iptables as root,without password ? thanks. [image: Istantanea_2024-05-13_17-40-21.png] On Mon, May 13, 2024 at 5:19 PM Mario Marietto wrote: > There is still a problem. If I login automatically as user and inside the > script I do this : > > sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE > > it asks me for the password (don't know why it didn't before) but I can't > issue a password,because the script inside the vm should work automatically > and should be hidden between the FreeBSD processes. > > On Mon, May 13, 2024 at 4:11 PM Stefan Monnier > wrote: > >> > You don't need to, but I definitely think he does. >> ^^ >> >> [ Oh, bias, when will you leave me alone? ] >> >> >> Stefan >> >> > > -- > Mario. > -- Mario.
Re: How to run automatically a script as soon root login
There is still a problem. If I login automatically as user and inside the script I do this : sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE it asks me for the password (don't know why it didn't before) but I can't issue a password,because the script inside the vm should work automatically and should be hidden between the FreeBSD processes. On Mon, May 13, 2024 at 4:11 PM Stefan Monnier wrote: > > You don't need to, but I definitely think he does. > ^^ > > [ Oh, bias, when will you leave me alone? ] > > > Stefan > > -- Mario.
Re: How to run automatically a script as soon root login
> You don't need to, but I definitely think he does. ^^ [ Oh, bias, when will you leave me alone? ] Stefan
Re: How to run automatically a script as soon root login
I've found that solution on the Internet. It wasn't the only solution that
I found,but that form won the challenge because it has found my mind ready
to detect that it could have worked. Maybe I could have used while,but
after 1 hour of thinking I didn't understand how and I resigned. The same
for until and for. Sorry for that,but I'm not an experienced coder. I try
to do my best with what I find on the Internet. I can adapt an already good
enough solution to fit my needs,but I'm not able to write a script from
scratch. It is also true that I found it good because it reminded me of my
old good times when I was a good basic and turbo pascal programmer.
On Mon, May 13, 2024 at 3:24 PM Nicolas George wrote:
> Mario Marietto (12024-05-13):
> > The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
> > doesn't work if invoked as a user,it says "you must be root". So,as
> > user,the script seems to be working fine like this :
> >
> > function jumpto
> > {
> > label=$1
> > cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> > eval "$cmd"
> > exit
> > }
>
> You seem to be investing a lot of effort into a fragile solution to
> emulate a deprecated execution control primitive.
>
> Regards,
>
> --
> Nicolas George
>
>
--
Mario.
Re: How to run automatically a script as soon root login
>> > echo 1 > /proc/sys/net/ipv4/ip_forward >> This doesn't sound right. Maybe you should investigate why you're > No need to “investigate”, the answer is obvious: in You don't need to, but I definitely think he does. Stefan
Re: How to run automatically a script as soon root login
Mario Marietto (12024-05-13):
> The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
> doesn't work if invoked as a user,it says "you must be root". So,as
> user,the script seems to be working fine like this :
>
> function jumpto
> {
> label=$1
> cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
> eval "$cmd"
> exit
> }
You seem to be investing a lot of effort into a fragile solution to
emulate a deprecated execution control primitive.
Regards,
--
Nicolas George
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 09:17:31AM -0400, Greg Wooledge wrote: > On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote: > > >> sudo xterm -e "echo 1 > hello" > > > Yes, but why did it allow me to delete the file? I was not root > > then. Try it. > > Because you have write permission on the *directory* that the file is in. > > Removing (unlinking) a file is an operation that modifies a directory, > not the file itself. You don't need write permission on the file. Just > the directory. Unless the directory has the sticky bit set (e.g. /tmp). (For completeness: I know you know that). Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
Le 13/05/2024 à 15:03, Richmond a écrit : Erwan David writes: Le 13/05/2024 à 14:36, Richmond a écrit : I was experimenting, and found this works: sudo xterm -e "echo 1 > hello" It created a file owned by root. But I found I was able to remove it without being root even though group and world permissions were read only. thats because sudo exceutes a xterm as root then this xterm executes a shell (as root) and this root shell does the redirection. Yes, but why did it allow me to delete the file? I was not root then. Try it. as said Dan Ritter : the owner of the directory can delete any file inside the directory. (see a directory as a special file containing pairs (name,file place on the disk). Deleting a file is just removing the pair from the directory, thus it is editing the directory, not the file. -- Erwan David
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 02:03:59PM +0100, Richmond wrote: > >> sudo xterm -e "echo 1 > hello" > Yes, but why did it allow me to delete the file? I was not root > then. Try it. Because you have write permission on the *directory* that the file is in. Removing (unlinking) a file is an operation that modifies a directory, not the file itself. You don't need write permission on the file. Just the directory.
Re: How to run automatically a script as soon root login
The command iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
doesn't work if invoked as a user,it says "you must be root". So,as
user,the script seems to be working fine like this :
function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
eval "$cmd"
exit
}
start=${1:-"start"}
jumpto $start
start:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
#echo 1 > /proc/sys/net/ipv4/ip_forward (because I've uncommented this
command inside the file /etc/sysctl.conf)
sudo iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo Connected to Cloudflare Warp...
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP
mid :
if [ "$OLD_IP = $NEW_IP ]
then
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it does not work
anymore,reconnecting...
sleep 10
jump foo
else
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it still works.
sleep 10
fi
jumpto mid
foo:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it works again.
jumpto mid
On Mon, May 13, 2024 at 2:59 PM wrote:
> On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote:
> > to...@tuxteam.de (12024-05-13):
> > > That's like slicing your morning baguette with the chainsaw.
> >
> > Worse than that, it will only work from an X11 environment. Certainly
> > not at boot.
>
> The analogy to that would be that not many kitchens are equipped with
> a chainsaw. Mine isn't ;-)
>
> Cheers
> --
> t
>
--
Mario.
Re: How to run automatically a script as soon root login
Richmond (12024-05-13): > sudo bash -c "echo 1 > hello" Use sh for that. Regards, -- Nicolas George
Re: How to run automatically a script as soon root login
Erwan David writes: > Le 13/05/2024 à 14:36, Richmond a écrit : >> I was experimenting, and found this works: >> >> sudo xterm -e "echo 1 > hello" >> >> It created a file owned by root. But I found I was able to remove it >> without being root even though group and world permissions were read >> only. >> >> > thats because sudo exceutes a xterm as root > > then this xterm executes a shell (as root) and this root shell does > the redirection. Yes, but why did it allow me to delete the file? I was not root then. Try it.
Re: How to run automatically a script as soon root login
writes: > On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote: >> I was experimenting, and found this works: >> >> sudo xterm -e "echo 1 > hello" > > That's like slicing your morning baguette with the chainsaw. I do that too. > > But if it works for you... hey :-) > > Cheers This also works: sudo bash -c "echo 1 > hello"
Re: How to run automatically a script as soon root login
Richmond wrote: > I was experimenting, and found this works: > > sudo xterm -e "echo 1 > hello" > > It created a file owned by root. But I found I was able to remove it > without being root even though group and world permissions were read > only. The owner of a directory can delete any file in it. -dsr-
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 02:53:18PM +0200, Nicolas George wrote: > to...@tuxteam.de (12024-05-13): > > That's like slicing your morning baguette with the chainsaw. > > Worse than that, it will only work from an X11 environment. Certainly > not at boot. The analogy to that would be that not many kitchens are equipped with a chainsaw. Mine isn't ;-) Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
to...@tuxteam.de (12024-05-13): > That's like slicing your morning baguette with the chainsaw. Worse than that, it will only work from an X11 environment. Certainly not at boot. Regards, -- Nicolas George
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 01:36:23PM +0100, Richmond wrote: > I was experimenting, and found this works: > > sudo xterm -e "echo 1 > hello" That's like slicing your morning baguette with the chainsaw. But if it works for you... hey :-) Cheers -- t signature.asc Description: PGP signature
Re: How to run automatically a script as soon root login
Le 13/05/2024 à 14:36, Richmond a écrit : I was experimenting, and found this works: sudo xterm -e "echo 1 > hello" It created a file owned by root. But I found I was able to remove it without being root even though group and world permissions were read only. thats because sudo exceutes a xterm as root then this xterm executes a shell (as root) and this root shell does the redirection. -- Erwan David
Re: How to run automatically a script as soon root login
I was experimenting, and found this works: sudo xterm -e "echo 1 > hello" It created a file owned by root. But I found I was able to remove it without being root even though group and world permissions were read only.
Re: How to run automatically a script as soon root login
Dan Ritter (12024-05-13): > Mario Marietto wrote:> If you run > > sudo echo 1 > /proc/sys/net/ipv4/ip_forward > > then the shell you are running it from will run "sudo echo 1" > and then try to put the output in that file. Other way around: the shell first tries to redirect the output to the file and then (if it succeeds) runs sudo that way. Regards, -- Nicolas George
Re: How to run automatically a script as soon root login
Mario Marietto wrote: > --> If they only want this thing to happen when root logs in directly on a > console or ssh, then .profile may indeed be the correct answer. > > Yes,I don't need to run xorg and a desktop environment,since warp-cli > disconnect and warp-cli connect do not require them. > I wouldn't to login as root automatically,but I've realized that this > command : > > echo 1 > /proc/sys/net/ipv4/ip_forward > > work only if I'm root. It does not work using sudo. So,in the end I've > chosen to be root instead of a normal user that can use sudo. If you run sudo echo 1 > /proc/sys/net/ipv4/ip_forward then the shell you are running it from will run "sudo echo 1" and then try to put the output in that file. That fails because the running process is owned by you, not root. If you put the echo command into a script, and then run the script with sudo, this will work. -dsr- then
Re: How to run automatically a script as soon root login
Stefan Monnier (12024-05-13): > > echo 1 > /proc/sys/net/ipv4/ip_forward > > > > work only if I'm root. It does not work using sudo. > This doesn't sound right. Maybe you should investigate why you're > seeing this behavior, rather than work around the problem. > > `sudo` *is* root. No need to “investigate”, the answer is obvious: in sudo foo > bar … the > bar comes before the sudo. Regards, -- Nicolas George
Re: How to run automatically a script as soon root login
> echo 1 > /proc/sys/net/ipv4/ip_forward > > work only if I'm root. It does not work using sudo. This doesn't sound right. Maybe you should investigate why you're seeing this behavior, rather than work around the problem. `sudo` *is* root. Stefan
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 01:48:25PM +0200, Mario Marietto wrote: > I wouldn't to login as root automatically,but I've realized that this > command : > > echo 1 > /proc/sys/net/ipv4/ip_forward > > work only if I'm root. It does not work using sudo. So,in the end I've > chosen to be root instead of a normal user that can use sudo. Aha! Classic X-Y problem. To do this with sudo, you can use a shell: sudo sh -c 'echo 1 > /proc/sys/net/ipv4/ip_forward' However, this particular setting can also be done with sysctl: sudo sysctl -w net.ipv4.ip_forward=1 Or if you just want the setting to be made permanent, edit the /etc/sysctl.conf file, find the line that says: # Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1 and remove the # sign in front of net.ipv4.ip_forward=1 and then you will never have to issue your command manually again.
Re: How to run automatically a script as soon root login
Le 13/05/2024 à 13:48, Mario Marietto a écrit : --> If they only want this thing to happen when root logs in directly on a console or ssh, then .profile may indeed be the correct answer. Yes,I don't need to run xorg and a desktop environment,since warp-cli disconnect and warp-cli connect do not require them. I wouldn't to login as root automatically,but I've realized that this command : echo 1 > /proc/sys/net/ipv4/ip_forward work only if I'm root. It does not work using sudo. So,in the end I've chosen to be root instead of a normal user that can use sudo. For this it is sufficient to use /etc/sysctl.conf You find in the file shipped by debian # Uncomment the next line to enable packet forwarding for IPv4 #net.ipv4.ip_forward=1 So you just have to uncomment and it will be done at boot time. (You have the ipv6 equivalent in the same file, if needed) -- Erwan David
Re: How to run automatically a script as soon root login
--> If they only want this thing to happen when root logs in directly on a console or ssh, then .profile may indeed be the correct answer. Yes,I don't need to run xorg and a desktop environment,since warp-cli disconnect and warp-cli connect do not require them. I wouldn't to login as root automatically,but I've realized that this command : echo 1 > /proc/sys/net/ipv4/ip_forward work only if I'm root. It does not work using sudo. So,in the end I've chosen to be root instead of a normal user that can use sudo. On Mon, May 13, 2024 at 1:24 PM Greg Wooledge wrote: > On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > > .profile > > will always be read as soon as the user logs in, no matter how. Through a > > terminal, a GUI, doesn't matter. > > That's not correct. There are many different GUI login setups where > the .profile is never read. > > That said, since this thread is specifically about *root* logins, GUI > logins may not be possible. It depends on which Display Manager and > Desktop Environment are in use. Many of them explicitly disallow direct > root logins. > > So, ultimately it comes down to what the OP actually requires, and > what type of setup they use. If they only want this thing to happen > when root logs in directly on a console or ssh, then .profile may > indeed be the correct answer. > > -- Mario.
Re: How to run automatically a script as soon root login
Hello to everyone,
Richard,thanks. I've launched the script inside the .profile file that's
inside the root folder and it worked. Thank you.
Plan B : From time to time the cloudflare connection stops working,so there
is the needing to repeat these commands :
warp-cli disconnect
warp-cli connect
At this point,I've modified the script like this one : (yes,I've been a
happy coder of BASIC and I feel the nostalgia of GOTO).
function jumpto
{
label=$1
cmd=$(sed -n "/$label:/{:a;n;p;ba};" $0 | grep -v ':$')
eval "$cmd"
exit
}
start=${1:-"start"}
jumpto $start
start:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
echo 1 > /proc/sys/net/ipv4/ip_forward
iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo Connected to Cloudflare Warp...
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP
mid :
if [ "$OLD_IP = $NEW_IP ]
then
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it does not work
anymore,reconnecting...
sleep 10
jump foo
else
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it still works.
sleep 10
fi
jumpto mid
foo:
warp-cli disconnect
OLD_IP="$(curl -s api.ipify.org)"
warp-cli connect
NEW_IP="$(curl -s api.ipify.org)"
echo OLD IP is $OLD_IP , NEW IP is $NEW_IP : it works again.
jumpto mid
On Mon, May 13, 2024 at 7:36 AM Richard wrote:
> Should be as easy as executing the script from the .profile of root - that
> means if "log in as root" actually means root, not just sudo'ing. .profile
> will always be read as soon as the user logs in, no matter how. Through a
> terminal, a GUI, doesn't matter. No idea if doing this through systemd is
> even possible.
>
> Best
> Richard
>
> On Mon, May 13, 2024, 04:10 Mario Marietto wrote:
>
>> Hello to everyone.
>>
>> I'm using Debian 12. I'm configuring a little Debian 12 vm with qemu that
>> I will use to forward the cloudflare connection to FreeBD.
>> What I want to do is to run the script below as soon as root has logged
>> in.
>>
>> I've configured the automatic login of root adding to this service file :
>>
>> nano /etc/systemd/system/getty.target.wants/getty@tty1.service
>>
>> this line :
>>
>> ExecStart=/sbin/agetty -o '-p -f -- \\u" --noclear --autologin root %I
>> $TERM
>>
>> Now,what I want to do is that the script below is ran as soon root is
>> able to logged in automatically :
>>
>> /usr/bin/warp
>>
>> warp-cli disconnect
>> echo 1 > /proc/sys/net/ipv4/ip_forward
>> iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE
>> OLD_IP="$(curl -s api.ipify.org)"
>> warp-cli connect
>> NEW_IP="$(curl -s api.ipify.org)"
>> echo Connected to Cloudflare Warp...
>> echo OLD IP is : $OLD_IP,NEW IP is : $NEW_IP
>>
>> [Forgot to say that I switched boot target to text with this command :
>>
>> sudo systemctl set-default multi-user.target]
>>
>> What I tried right now has been to create a respawn service with systemd.
>> I created a file in /etc/systemd/system/ i.e. warp.service
>>
>> [Unit]
>> Desription=warp with systemd, respawn
>> After=pre-network.target
>>
>> [Service]
>> ExecStart=/usr/bin/warp
>> Restart=always
>>
>> [Install]
>> WantedBy=multi-user.target
>>
>>
>> and I've activated it :
>>
>> systemctl enable warp.service
>>
>>
>> rebooted and started it manually :
>>
>> systemctl daemon-reload
>> systemctl start warp.service
>>
>> It does not work and anyway it does not seem to be what I want...
>>
>> [image: Istantanea_2024-05-12_23-46-37.png]
>>
>> I want that the warp script is run everytime root is logged in,not
>> more,not less.
>> I suspect that the solution is easier than what I'm trying to do...
>>
>> --
>> Mario.
>>
>
--
Mario.
Re: How to run automatically a script as soon root login
On Mon, May 13, 2024 at 07:36:07AM +0200, Richard wrote: > .profile > will always be read as soon as the user logs in, no matter how. Through a > terminal, a GUI, doesn't matter. That's not correct. There are many different GUI login setups where the .profile is never read. That said, since this thread is specifically about *root* logins, GUI logins may not be possible. It depends on which Display Manager and Desktop Environment are in use. Many of them explicitly disallow direct root logins. So, ultimately it comes down to what the OP actually requires, and what type of setup they use. If they only want this thing to happen when root logs in directly on a console or ssh, then .profile may indeed be the correct answer.
Re: How to run automatically a script as soon root login
Should be as easy as executing the script from the .profile of root - that means if "log in as root" actually means root, not just sudo'ing. .profile will always be read as soon as the user logs in, no matter how. Through a terminal, a GUI, doesn't matter. No idea if doing this through systemd is even possible. Best Richard On Mon, May 13, 2024, 04:10 Mario Marietto wrote: > Hello to everyone. > > I'm using Debian 12. I'm configuring a little Debian 12 vm with qemu that > I will use to forward the cloudflare connection to FreeBD. > What I want to do is to run the script below as soon as root has logged > in. > > I've configured the automatic login of root adding to this service file : > > nano /etc/systemd/system/getty.target.wants/getty@tty1.service > > this line : > > ExecStart=/sbin/agetty -o '-p -f -- \\u" --noclear --autologin root %I > $TERM > > Now,what I want to do is that the script below is ran as soon root is able > to logged in automatically : > > /usr/bin/warp > > warp-cli disconnect > echo 1 > /proc/sys/net/ipv4/ip_forward > iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE > OLD_IP="$(curl -s api.ipify.org)" > warp-cli connect > NEW_IP="$(curl -s api.ipify.org)" > echo Connected to Cloudflare Warp... > echo OLD IP is : $OLD_IP,NEW IP is : $NEW_IP > > [Forgot to say that I switched boot target to text with this command : > > sudo systemctl set-default multi-user.target] > > What I tried right now has been to create a respawn service with systemd. > I created a file in /etc/systemd/system/ i.e. warp.service > > [Unit] > Desription=warp with systemd, respawn > After=pre-network.target > > [Service] > ExecStart=/usr/bin/warp > Restart=always > > [Install] > WantedBy=multi-user.target > > > and I've activated it : > > systemctl enable warp.service > > > rebooted and started it manually : > > systemctl daemon-reload > systemctl start warp.service > > It does not work and anyway it does not seem to be what I want... > > [image: Istantanea_2024-05-12_23-46-37.png] > > I want that the warp script is run everytime root is logged in,not > more,not less. > I suspect that the solution is easier than what I'm trying to do... > > -- > Mario. >
Re: How to run automatically a script as soon root login
On Sun 12/05/2024 at 22:52, Mario Marietto wrote: > I want that the warp script is run everytime root is logged in,not more,not > less. The second half of this seems to do what you want https://stackoverflow.com/a/39024841
How to run automatically a script as soon root login
Hello to everyone. I'm using Debian 12. I'm configuring a little Debian 12 vm with qemu that I will use to forward the cloudflare connection to FreeBD. What I want to do is to run the script below as soon as root has logged in. I've configured the automatic login of root adding to this service file : nano /etc/systemd/system/getty.target.wants/getty@tty1.service this line : ExecStart=/sbin/agetty -o '-p -f -- \\u" --noclear --autologin root %I $TERM Now,what I want to do is that the script below is ran as soon root is able to logged in automatically : /usr/bin/warp warp-cli disconnect echo 1 > /proc/sys/net/ipv4/ip_forward iptables -A POSTROUTING -t nat -s 192.168.1.5 -j MASQUERADE OLD_IP="$(curl -s api.ipify.org)" warp-cli connect NEW_IP="$(curl -s api.ipify.org)" echo Connected to Cloudflare Warp... echo OLD IP is : $OLD_IP,NEW IP is : $NEW_IP [Forgot to say that I switched boot target to text with this command : sudo systemctl set-default multi-user.target] What I tried right now has been to create a respawn service with systemd. I created a file in /etc/systemd/system/ i.e. warp.service [Unit] Desription=warp with systemd, respawn After=pre-network.target [Service] ExecStart=/usr/bin/warp Restart=always [Install] WantedBy=multi-user.target and I've activated it : systemctl enable warp.service rebooted and started it manually : systemctl daemon-reload systemctl start warp.service It does not work and anyway it does not seem to be what I want... [image: Istantanea_2024-05-12_23-46-37.png] I want that the warp script is run everytime root is logged in,not more,not less. I suspect that the solution is easier than what I'm trying to do... -- Mario.
Re: Using a Python script as a login shell
Hey this looks like a fun thing to play with, I like what you've done. I logged in and accessed it. Now that it's been some time since you announced it and it's still running, I guess it has had some testing already. I don't see anything wrong with what you have done after a quick look, it seems like you took some steps to secure it. If you care about security you want to think about defense in depth. Even if there don't appear to be ways for arbitrary filesystem or network access to happen, you have to consider the effect of bugs in your program and bugs in python itself. To protect against unwanted filesystem access, I suggest: * use a vm without anything else important on it * consider filesystem quotas * lock down the user as much as possible. Consider e.g. apparmor or selinux. Maybe consider containerization/capabilities inside the VM To protect against unwanted network access: * prevent all outgoing network connections from the VM using iptables/nftables (or whitelist any that are necessary) * again consider networking restrictions using apparmor or selinux. What level of protection is necessary will depend on the severity of impact in the case it gets hacked, and also your own level of conscientiousness. Also consider putting in some monitoring; monitor network bandwith and CPU usage at least (perhaps # of logins as well) and set up an alert if those go outside limits, so you get timely notification if something should happen. Have fun, Alex P.S. this brings to mind https://en.wikipedia.org/wiki/Russell_Coker#SELinux_Play_Machine, which is no longer operating. When you say "expose it to the internet via SSH", do you mean expose it to everyone (e.g. by publishing the pssword), or will there still be some restrictions on who can access it? If the former, you should be able to set up ssh without any password required. On 16/02/24 21:36, Ralph Aichinger wrote: Hello fellow Debianites! I want do do a custom CLI for a project, and I am quite happy with the Python cmd module. Aside from having a practically un-googleable name it is very nice, and does a lot with very little code. So far, so good. But: If I write a Python script with this module, and expose it to the internet via SSH, will hell break loose? So far I've done the following: 1. Put my script in /usr/local/bin/turtle (the canonical example in the docs is something with turtle), you can see the sourcecode of my script here: https://pi.h5.or.at/mockturtle.txt This script does absolutely nothing sensible, you can try it out by doing a ssh -l admin probe.aisg.at from a IPv6 capable host (sorry, no IPv4). The password is "admin". Any and all suggestions on stuff that is stupid and crazy from a security standpoint in this script are very much appreciated! 2. Then I put /usr/local/bin/turtle in /etc/shells 3. I added a user "admin" that has /usr/local/bin/turtle as shell 4. I added following stanza to /etc/ssh/sshd_config Match User admin X11Forwarding no AllowTcpForwarding no ForceCommand /usr/local/bin/turtle 5. In the script I tried to catch the Ctrl-C signal, so the interpreter does not give out too obvious error messages (that show what is going on behind the scenes). Is this enough to harden this setup against escaping into a shell or the full python interpreter, to do something nasty? Or is it completely crazy, because theere is some way to abuse a setup like this, that I have not found yet? TIA Ralph
Using a Python script as a login shell
Hello fellow Debianites! I want do do a custom CLI for a project, and I am quite happy with the Python cmd module. Aside from having a practically un-googleable name it is very nice, and does a lot with very little code. So far, so good. But: If I write a Python script with this module, and expose it to the internet via SSH, will hell break loose? So far I've done the following: 1. Put my script in /usr/local/bin/turtle (the canonical example in the docs is something with turtle), you can see the sourcecode of my script here: https://pi.h5.or.at/mockturtle.txt This script does absolutely nothing sensible, you can try it out by doing a ssh -l admin probe.aisg.at from a IPv6 capable host (sorry, no IPv4). The password is "admin". Any and all suggestions on stuff that is stupid and crazy from a security standpoint in this script are very much appreciated! 2. Then I put /usr/local/bin/turtle in /etc/shells 3. I added a user "admin" that has /usr/local/bin/turtle as shell 4. I added following stanza to /etc/ssh/sshd_config Match User admin X11Forwarding no AllowTcpForwarding no ForceCommand /usr/local/bin/turtle 5. In the script I tried to catch the Ctrl-C signal, so the interpreter does not give out too obvious error messages (that show what is going on behind the scenes). Is this enough to harden this setup against escaping into a shell or the full python interpreter, to do something nasty? Or is it completely crazy, because theere is some way to abuse a setup like this, that I have not found yet? TIA Ralph
[HS] assistance au code (Re: Script BASH gestion des espaces des noms de fichier)
Bonjour, Le 2024-02-05 16:07, Daniel Caillibaud a écrit : Oui, et je vous encourage à passer vos shell bash à shellcheck, il signale ce genre d'erreur (et plein d'autres). Il est parfois un peut trop zélé, mais on peut lui dire qu'on sait ce qu'on fait avec du # shellcheck disable=SC avant la ligne qui le fait râler (où est le code d'erreur qu'il signale) Avec Neovim, on peut avoir ce genre d'assistance en direct :) Sébastien
Re: Script BASH gestion des espaces des noms de fichier
Le 02/02/24 à 08:54, Jérémy Prego a écrit : > Pour éviter ce problème, on peut mettre les variables entre " > > du coup, ça donnerai: > > pdftk "$fichier1" stamp "$tampon" output "$fichier2" Oui, et je vous encourage à passer vos shell bash à shellcheck, il signale ce genre d'erreur (et plein d'autres). Il est parfois un peut trop zélé, mais on peut lui dire qu'on sait ce qu'on fait avec du # shellcheck disable=SC avant la ligne qui le fait râler (où est le code d'erreur qu'il signale) -- Daniel La pensée vole et les mots vont à pied. Voilà tout le drame de l'écrivain. Julien Green
Re: script/history
On Mon 05/02/2024 at 00:45, Greg Wooledge wrote: ... > If you're one of these "I want every command I ever run to be in my > shell history, retained forever, and I don't care how much space it > takes" people, then there are web pages out there that can help you. > I don't follow that philosophy myself, so I can't give you specific > variables and settings. But Google can. I find a long history useful, and have already googled for such, though I should perhaps rotate it at some point :) Thanks for the detailed explanation. G
Re: script/history
(Re)posting the below as requested, and can confirm history -r seems to have the desired effect. Thanks. - Original message - From: Will Mengarini To: Gareth Evans Cc: debian-user@lists.debian.org Subject: Re: script/history Date: Monday, 5 February 2024 01:02 * Gareth Evans [24-02/04=Su 09:46 +]: > Re the script command, does anyone know of a way to make > commands run during a script session appear in bash history too? You want the 'history -r' command, "explained" by `help history`. After you end the script, you're back in the bash instance you ran 'script' from. When you ended the script & therefore the bash being run in that script, that bash wrote its commands to ~/.bash_history; but the bash you're running, which is the one you ran script from, hasn't read that ~/.bash_history. Running 'history -r' will cause it to do so. BTW I've got some kind of email configuration problem that usually prevents me from posting to debian-user, even though I can usually email individual users. Gareth, if you get this, and it's the correct solution to your original problem, perhaps you could post it to the list; this email is CCd to debian-user, but I expect the CC to bounce.
Re: script/history
* Gareth Evans [24-02/04=Su 09:46 +]: > Re the script command, does anyone know of a way to make > commands run during a script session appear in bash history too? You want the 'history -r' command, "explained" by `help history`. After you end the script, you're back in the bash instance you ran 'script' from. When you ended the script & therefore the bash being run in that script, that bash wrote its commands to ~/.bash_history; but the bash you're running, which is the one you ran script from, hasn't read that ~/.bash_history. Running 'history -r' will cause it to do so. BTW I've got some kind of email configuration problem that usually prevents me from posting to debian-user, even though I can usually email individual users. Gareth, if you get this, and it's the correct solution to your original problem, perhaps you could post it to the list; this email is CCd to debian-user, but I expect the CC to bounce.
Re: script/history
On Mon, Feb 05, 2024 at 12:28:38AM +, Gareth Evans wrote: > I was trying to view the history of commands run during a script session. > > user@qwerty:~$ script foo > Script started, output log file is 'foo'. > user@qwerty:~$ date > Mon 5 Feb 00:21:16 GMT 2024 > user@qwerty:~$ exit > exit > Script done. > user@qwerty:~$ history |tail -n3 > 30914 2024-02-04 23:44:24 man script > 30915 2024-02-05 00:21:15 script foo > 30916 2024-02-05 00:21:25 history |tail -n3 # NB "date" is missing > > Michael Grant pointed out (among other things) that the history is available, > but not in the terminal in which script has just exited. OK. Well, start by thinking about what happens if you're in a bash shell, and you type "bash". You get a second bash instance, which is a child process of the original shell. The original shell goes to sleep, and waits for the child to exit. When the child process starts up, it reads the .bash_history file (unless you changed the variable that names the file), thereby loading the shell history from disk into memory. Then you run whatever commands you run, and those are appended to the in-memory shell history. Then you exit, at which point bash rewrites the .bash_history file. After exiting from the child shell, you're back in the original shell. The original shell's in-memory history did not change during the child's lifetime. The only change to the in-memory history is the addition of a "bash" command. The .bash_history file has been changed, but the running shell doesn't read that to get the new contents in memory. If/when you exit from the original shell, the .bash_history file will be rewritten again, using the in-memory history of the original bash instance. This does *not* include any changes that were written by the child process. Those changes may simply be lost. It depends on which history options you've chosen, and how many new commands were appended to the original shell's in-memory history before exiting. Once you understand all of this, then it should be obvious how "script" works. It runs a new instance of "bash". As far as history goes, it works exactly like the above. The only difference is you've also got a file containing a recording of the terminal session. If you're one of these "I want every command I ever run to be in my shell history, retained forever, and I don't care how much space it takes" people, then there are web pages out there that can help you. I don't follow that philosophy myself, so I can't give you specific variables and settings. But Google can.
Re: script/history
On Sun 04/02/2024 at 19:45, David Wright wrote: ... > According to this man page for csh (but includes tcsh): > > https://linux.die.net/man/1/csh > > the "a" that modifies modifiers is a "[feature] of tcsh not found > in most csh(1) implementations (specifically, the 4.4BSD csh)". It > appears that bash supports it syntactically, but not its semantics. > I'm not sure why you mentioned this shell detail specifically. I was just highlighting a way to see if behaviour differs between bash "proper" and script running in bash. cf. "a (+) Apply the following modifier as many times as possible to a single word ..." https://linux.die.net/man/1/csh "a Cause changes to be applied over the entire event line ..." https://www.gnu.org/software/bash/manual/bash.html#Word-Designators Thanks Gareth
Re: script/history
On Sun 04/02/2024 at 17:33, Greg Wooledge wrote: ... > The script(1) utility has NOTHING to do with running ordinary shell > scripts. I understand that. I was trying to view the history of commands run during a script session. user@qwerty:~$ script foo Script started, output log file is 'foo'. user@qwerty:~$ date Mon 5 Feb 00:21:16 GMT 2024 user@qwerty:~$ exit exit Script done. user@qwerty:~$ history |tail -n3 30914 2024-02-04 23:44:24 man script 30915 2024-02-05 00:21:15 script foo 30916 2024-02-05 00:21:25 history |tail -n3 # NB "date" is missing Michael Grant pointed out (among other things) that the history is available, but not in the terminal in which script has just exited. Meanwhile, I read man script and wondered if csh, or even just csh's approach to history manipulation, was somehow involved. I was then a little surprised to see user@qwerty:~$ csh # bash prompt % script foo # csh prompt Script started, output log file is 'foo'. user@qwerty:~$ date# bash prompt in script in csh in bash Sun 4 Feb 23:25:14 GMT 2024 user@qwerty:~$ exit exit Script done. % exit % exit user@qwerty:~$ although on a "native" csh system, I would expect script to "present" csh, not bash. I I am left with the impression that script may impose csh's history substitution/manipulation approach/syntax (for what differences there may be) regardless of which shell it's running from, and that that is the reason for the reference to csh for the "history mechanism" in man script. Thanks Gareth
Re: script/history
On Sun, Feb 04, 2024 at 01:45:27PM -0600, David Wright wrote: > SCRIPT(1) User Commands SCRIPT(1) > [ … ] > HISTORY > The script command appeared in 3.0BSD. > > I have no idea why "the history mechanism" is even mentioned > in the man page for script. It appears in the FreeBSD man page as well, but not the OpenBSD man page. https://man.freebsd.org/cgi/man.cgi?script https://man.openbsd.org/script I don't understand why that parenthetical comment is in the FreeBSD man page either, but it was clearly copied over to the util-linux man page without modification. Another thing I don't understand is what the OP of this thread was trying to do in the first place.
Re: script/history
On Sun 04 Feb 2024 at 16:01:29 (+), Gareth Evans wrote: > On Sun 04/02/2024 at 13:24, Max Nikulin wrote: > > On 04/02/2024 16:46, Gareth Evans wrote: > >> Re the script command, does anyone know of a way [ … ] > > [...] > >> man script says > >> > >> "SEE ALSO > >> csh(1) (for the history mechanism)" My take on this is that the man page was originally written for BSD, which lies on the csh side of the "great divide" rather than the sh/bash side. SCRIPT(1) User Commands SCRIPT(1) [ … ] HISTORY The script command appeared in 3.0BSD. I have no idea why "the history mechanism" is even mentioned in the man page for script. > The function of the "a" option in History Substitution in man csh seems > different in the bash version.(under "Word Designators" in man bash/gnu > online manual) According to this man page for csh (but includes tcsh): https://linux.die.net/man/1/csh the "a" that modifies modifiers is a "[feature] of tcsh not found in most csh(1) implementations (specifically, the 4.4BSD csh)". It appears that bash supports it syntactically, but not its semantics. I'm not sure why you mentioned this shell detail specifically. Cheers, David.
Re: script/history
On Sun, Feb 04, 2024 at 04:01:29PM +, Gareth Evans wrote: > It seemed to me initially (as I should perhaps have stated) that man script > was suggesting that csh was a component or depedency (of script), which > seemed to be contradicted by it not being installed. On reflection, > possibly, it's just a way of doing things in script. The reference in man > script now seems to imply the latter. > > The fact that script scripts bash on my machine made me not think about the > fact that it probably scripts whatever shell it's running from, and was > doubtless written with one in mind/as inspiration - csh might make a certain > sense in that respect. > > script runs in bash if run from csh run from bash, but I suppose csh in that > chain of shells isn't a proper [do I mean login?] shell. (Got that? :p) You're so confused that I can't even figure out where to start! So let me start here: The script(1) utility exists to RECORD a session so that you can play it back later and see what happened. One recommended use of this tool is to record the session in which you do a dist-upgrade, say, from Debian 11 to Debian 12. Then if anything goes wrong, you can look back through the session's logfile and see what happened, and try to fix it. The script(1) utility has NOTHING to do with running ordinary shell scripts.
Re: script/history
On Sun 04/02/2024 at 13:24, Max Nikulin wrote: > On 04/02/2024 16:46, Gareth Evans wrote: >> Re the script command, does anyone know of a way to make commands run during >> a script session appear in bash history too? > [...] >> man script says >> >> "SEE ALSO >> csh(1) (for the history mechanism)" >> >> but >> >> $ man csh >> No manual entry for csh > > echo $SHELL > > If you really use BASH then install bash-doc, it contains manual in > various formats, including texinfo (info "bash") or read it online > https://www.gnu.org/software/bash/manual/ > it describes some options related to history handling Actually "man > bash" is something rather close, but it does not allow to save links to > specific sections. Hi Max, Thanks for links and suggestions. It seemed to me initially (as I should perhaps have stated) that man script was suggesting that csh was a component or depedency (of script), which seemed to be contradicted by it not being installed. On reflection, possibly, it's just a way of doing things in script. The reference in man script now seems to imply the latter. The fact that script scripts bash on my machine made me not think about the fact that it probably scripts whatever shell it's running from, and was doubtless written with one in mind/as inspiration - csh might make a certain sense in that respect. script runs in bash if run from csh run from bash, but I suppose csh in that chain of shells isn't a proper [do I mean login?] shell. (Got that? :p) The function of the "a" option in History Substitution in man csh seems different in the bash version.(under "Word Designators" in man bash/gnu online manual) It'll be interesting to test when I can make sense of it :p Anyway, my orginal question has been answered. Thanks all. Gareth
Re: script/history
Oh you're right, I entirely overlooked the usage of 'script' and didn't understand the question right, sorry. On Sun, 2024-02-04 at 06:28 -0500, Michael Grant wrote: > > $ script foo.txt > > Script started, output log file is 'foo.txt'. > > $ date > > Sun 4 Feb 09:44:00 GMT 2024 > > $ exit > > exit > > Script done. > > $ history|tail -n2 > > 30797 2024-02-04 09:43:57 script foo.txt > > 30798 2024-02-04 09:44:21 history|tail -n2 > > > > I did try to search on this but just got lots of "bash history" and > > "history in > > bash script" references. > > So this might surprise you but the commands are actually in the > history list! But not in the current shell. > > What happens is this: > > You start 'script foo.txt' and this starts a sub bash shell on a > different pseudo tty. You run some commands, it appends each command > to the history of this sub-shell's history. > > You then exit your script. Those commands you ran are at the bottom > of .bash_history (try to cat that file out after you exit script and > you should see them). > > But those commands are not sucked into the history of your current > shell. Then, you log out (or exit) your current shell and the history > of that shell overwrites the history of the previous one. > > If all you want to do is save off the commands after you exit your > script session, then simply move or copy .bash_history out of the way > before it gets overwritten. > > You might consider setting $HISTFILE to some other location other than > .bash_history. > > Michael Grant
Re: script/history
On 04/02/2024 16:46, Gareth Evans wrote: Re the script command, does anyone know of a way to make commands run during a script session appear in bash history too? [...] man script says "SEE ALSO csh(1) (for the history mechanism)" but $ man csh No manual entry for csh echo $SHELL If you really use BASH then install bash-doc, it contains manual in various formats, including texinfo (info "bash") or read it online https://www.gnu.org/software/bash/manual/ it describes some options related to history handling Actually "man bash" is something rather close, but it does not allow to save links to specific sections.
Re: script/history
On Sun, Feb 04, 2024 at 09:46:09AM +, Gareth Evans wrote: > man script says > > "SEE ALSO >csh(1) (for the history mechanism)" > > but > > $ man csh > No manual entry for csh I'm so glad that we're entering an era where it's normal *not* to have csh installed and used. That shell really was a disaster. Anyway, if you want to read man pages for packages that are not installed on your system, the World Wide Web is a good source. Specifically, you could start with <https://manpages.debian.org/csh> and see where that takes you.
Re: script/history
> $ script foo.txt > Script started, output log file is 'foo.txt'. > $ date > Sun 4 Feb 09:44:00 GMT 2024 > $ exit > exit > Script done. > $ history|tail -n2 > 30797 2024-02-04 09:43:57 script foo.txt > 30798 2024-02-04 09:44:21 history|tail -n2 > > I did try to search on this but just got lots of "bash history" and "history > in > bash script" references. So this might surprise you but the commands are actually in the history list! But not in the current shell. What happens is this: You start 'script foo.txt' and this starts a sub bash shell on a different pseudo tty. You run some commands, it appends each command to the history of this sub-shell's history. You then exit your script. Those commands you ran are at the bottom of .bash_history (try to cat that file out after you exit script and you should see them). But those commands are not sucked into the history of your current shell. Then, you log out (or exit) your current shell and the history of that shell overwrites the history of the previous one. If all you want to do is save off the commands after you exit your script session, then simply move or copy .bash_history out of the way before it gets overwritten. You might consider setting $HISTFILE to some other location other than .bash_history. Michael Grant signature.asc Description: PGP signature
Re: script/history
On Sun, 2024-02-04 at 09:46 +, Gareth Evans wrote: > Re the script command, does anyone know of a way to make commands > run during a script session appear in bash history too? Maybe this: https://serverfault.com/questions/16204/how-to-make-bash-scripts-print-out-every-command-before-it-executes It seems awkward to have scripts being put into the history. You could do something like cat script.sh >> ~/.bash_history maybe. How would that be useful?
script/history
Re the script command, does anyone know of a way to make commands run during a script session appear in bash history too? $ script foo.txt Script started, output log file is 'foo.txt'. $ date Sun 4 Feb 09:44:00 GMT 2024 $ exit exit Script done. $ history|tail -n2 30797 2024-02-04 09:43:57 script foo.txt 30798 2024-02-04 09:44:21 history|tail -n2 I did try to search on this but just got lots of "bash history" and "history in bash script" references. man script says "SEE ALSO csh(1) (for the history mechanism)" but $ man csh No manual entry for csh Thanks Gareth
Re: Script BASH gestion des espaces des noms de fichier
Essaie des cotes dans tes attributions de noms.
Par exemple :
TOTO="${NomFic}"
avec
NomFic="Mon Fichier"
Pareillement cote les appels :
Cmd —variable "${NomFic}"
Par exemple. Le fait de coter l’appel de variable avec des double cote permet à
BASH de considérer NomFic comme un seul paramètre envoyé à Cmd avec ses blancs.
Après il faut savoir comment la commande Cmd va traiter tout ça…
> Le 2 févr. 2024 à 07:51, Informatique BILLARD
> a écrit :
>
> Bonjour
>
> j'ai écrit un petit script qui lance à la fin cette commande :
>
> pdftk $fichier1 stamp $tampon output $fichier2
>
> avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres
> fournis au script .
>
> Mais je rencontre un problème quand il y a un espace dans le nom de fichier
> ou le répertoire pour pdftk ces espaces engendrent une erreur.
>
> J'ai pourtant placé l'antislah avant mes espace dans l'affectation des
> variables.
>
> tampon=/user/Document/cachet\ pdf
>
> Merci par avance
>
> François-Marie
>
--
Pierre Malard
Responsable architectures système CDS DINAMIS/THEIA Montpellier
IRD - UMR Espace-Dev - UAR CPST - IR Data-Terra
Maison de la Télédétection
500 rue Jean-François Breton
34093 Montpellier Cx 5
France
« SPAM : Spieced Pork and Meat »
Pierre Dac (Londres, 1944)
Extrait de « Pierre DAC parle au Français » sur Radio Londres, le 24 mars 1944,
dans Drôle de guerre, éditions Omnibus (2008), pages 93 à 96.
(https://www.epi.asso.fr/revue/articles/a1602d.htm)
|\ _,,,---,,_
/,`.-'`'-. ;-;;,_
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_) πr
perl -e '$_=q#: 3|\ 5_,3-3,2_: 3/,`.'"'"'`'"'"' 5-. ;-;;,_: |,A- ) )-,_. ,\
( `'"'"'-'"'"': '"'"'-3'"'"'2(_/--'"'"' `-'"'"'\_):
24πr::#;y#:#\n#;s#(\D)(\d+)#$1x$2#ge;print'
- --> Ce message n’engage que son auteur <--
signature.asc
Description: Message signed with OpenPGP
Re: Script BASH gestion des espaces des noms de fichier
Effectivement François Merci d'avoir rectifié. Erwann Le 02/02/2024 à 13:09, François TOURDE a écrit : Le 19755ième jour après Epoch, Erwann Le Bras écrivait: Éviter les boucles "for" avec listes de fichiers (for f in `ls "$dir"`) ou (for f in *), les espaces sont mal interprétés. Ça marche très bien l'utilisation avec for f in *, si tu prends soin d'utiliser "$f" plutôt que juste $f Par contre, le "in `ls *`" n'est effectivement pas une bonne idée.
Re: Script BASH gestion des espaces des noms de fichier
Le 19755ième jour après Epoch, Erwann Le Bras écrivait: > Éviter les boucles "for" avec listes de fichiers (for f in `ls > "$dir"`) ou (for f in *), les espaces sont mal interprétés. Ça marche très bien l'utilisation avec for f in *, si tu prends soin d'utiliser "$f" plutôt que juste $f Par contre, le "in `ls *`" n'est effectivement pas une bonne idée.
Re: Script BASH gestion des espaces des noms de fichier
bonjour
comme dis par ailleurs, pas de problème avec les espaces si les
variables et chemins sont bien protégés avec des doubles-cotes (["])
fichier="mon fichier"
dir="$HOME/mon répertoire"
cp "$fichier" "$dir"
Éviter les boucles "for" avec listes de fichiers (for f in `ls "$dir"`)
ou (for f in *), les espaces sont mal interprétés.
À la place utiliser "find" : find "$dir" -name "${fichier}*" -exec
c'est à peu près tout.
Erwann
Le 02/02/2024 à 08:41, Informatique BILLARD a écrit :
Bonjour
j'ai écrit un petit script qui lance à la fin cette commande :
pdftk $fichier1 stamp $tampon output $fichier2
avec $fichier1 et $tampon, $fichier2 sont construit à partir des
paramètres fournis au script .
Mais je rencontre un problème quand il y a un espace dans le nom de
fichier ou le répertoire pour pdftk ces espaces engendrent une erreur.
J'ai pourtant placé l’antislash avant mes espace dans l'affectation
des variables.
tampon=/user/Document/cachet*\ *pdf
Merci par avance
François-Marie
Re: Script BASH gestion des espaces des noms de fichier
merci je ne connaissais pas cet outils François-Marie Le 02/02/2024 à 09:54, Klaus Becker a écrit : Detox est ton ami Klaus
Re: Script BASH gestion des espaces des noms de fichier
Bon j'ai tourné le problème dans tous les sens et finalement j'ai opté pour ceci 1. le nom du fichier passé comme argument au script est traité pour remplacer les espaces par des underscore. 2. je fait un renommage de ce fichier avec le nom sans espaces. 3. Puis traitement et tout fonctionne. Merci à vous. François-Marie Le 02/02/2024 à 08:57, Cyrille a écrit : Bjr, tampon=/user/Document/cachet\ pdf et tampon="/user/Document/cachet\ pdf" (utiliser des double quote ?? ++
Re: Script BASH gestion des espaces des noms de fichier
Detox est ton ami Klaus
Re: Script BASH gestion des espaces des noms de fichier
Le 02/02/2024 à 08:48, Basile Starynkevitch a écrit : On 2/2/24 08:41, Informatique BILLARD wrote: Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Une solution simple c'est de s'interdire les espaces dans les noms de fichiers. Pourquoi ne pas coder par exemple Oui en effet j'ai fini par supprimer les espaces dans les noms de fichiers et répertoires. Cependant ce script traite des fichiers ayant parfois des espaces et si je dois renommer à chaque fois je vais perdre l'intérêt du script. tampon=/user/Document/cachet.pdf et ensuite lancer votre script avec /bin/bash -vx lescriptbash Merci par avance François-Marie
Script BASH gestion des espaces des noms de fichier
Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l'antislah avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Merci par avance François-Marie
Re: Script BASH gestion des espaces des noms de fichier
Bjr, > tampon=/user/Document/cachet\ pdf et tampon="/user/Document/cachet\ pdf" (utiliser des double quote ?? ++
Re: Script BASH gestion des espaces des noms de fichier
bonjour, Le 02/02/2024 à 08:41, Informatique BILLARD a écrit : Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 Pour éviter ce problème, on peut mettre les variables entre " du coup, ça donnerai: pdftk "$fichier1" stamp "$tampon" output "$fichier2" avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Merci par avance François-Marie Jerem
Re: Script BASH gestion des espaces des noms de fichier
On 2/2/24 08:41, Informatique BILLARD wrote: Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Une solution simple c'est de s'interdire les espaces dans les noms de fichiers. Pourquoi ne pas coder par exemple tampon=/user/Document/cachet.pdf et ensuite lancer votre script avec /bin/bash -vx lescriptbash Merci par avance François-Marie -- Basile Starynkevitch (only mine opinions / les opinions sont miennes uniquement) 92340 Bourg-la-Reine, France web page: starynkevitch.net/Basile/ See/voir: https://github.com/RefPerSys/RefPerSys
Script BASH gestion des espaces des noms de fichier
Bonjour j'ai écrit un petit script qui lance à la fin cette commande : pdftk $fichier1 stamp $tampon output $fichier2 avec $fichier1 et $tampon, $fichier2 sont construit à partir des paramètres fournis au script . Mais je rencontre un problème quand il y a un espace dans le nom de fichier ou le répertoire pour pdftk ces espaces engendrent une erreur. J'ai pourtant placé l’antislash avant mes espace dans l'affectation des variables. tampon=/user/Document/cachet*\ *pdf Merci par avance François-Marie
Re: Shell-script variable name case [WAS: Re: can you parse and "tail" at once? (and if you can't why not?)]
On 23/10/2023 10:56, David wrote: Hi, for your info, this convention is specified by POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Which says: Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2017 consist solely of uppercase letters, digits, and the ( '_' ) from the characters defined in Portable Character Set and do not begin with a digit. And: The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities. That's good to know, and pretty much invalidates everything I said. -- BOFH excuse #239: CPU needs bearings repacked Eduardo M KALINOWSKI edua...@kalinowski.com.br
Shell-script variable name case [WAS: Re: can you parse and "tail" at once? (and if you can't why not?)]
On Mon, 23 Oct 2023 at 13:25, Eduardo M KALINOWSKI wrote: > On 22/10/2023 23:13, Greg Wooledge wrote: > > 2) All-caps variable name IFL. All-caps variable names are reserved, > >by convention, for environment variables (e.g. PATH) and special > >shell variables (e.g. IFS). > While I don't disagree with the suggestion of using lower case for > variables (and have even started doing so myself), it seems that this > "convention" is far from universal. > I did a quick search on the bash manual page and found no suggestion on > how to name user variables, or that uppercase names are reserved (but it > was a very quick search - I might have skipped something). > Even an internet search shows that people seem to be divided: Hi, for your info, this convention is specified by POSIX: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html Which says: Environment variable names used by the utilities in the Shell and Utilities volume of POSIX.1-2017 consist solely of uppercase letters, digits, and the ( '_' ) from the characters defined in Portable Character Set and do not begin with a digit. And: The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.
Re: udev: Lancer un script à l'insertion d'une clé USB
Le 2023-10-12 14:20, Fabrice Delvallée a écrit : J'ai pas encore testé le service. Je suis novice en systemd et je ne sais pas non plus demandé a udev de monter la clé :) Voilà le contenu du fichier `/etc/systemd/system/backup.service` ``` [Unit] Description=Backup [Service] Type=oneshot ExecStart=/usr/local/sbin/backup.pl TimeoutSec=0 GuessMainPID=false RemainAfterExit=no ``` La commande `systemctl daemon-reload` permet à Systemd de prendre connaissance de ton nouveau service. Je t'épargne le contenu de mon `backup.pl` qui est trop spécifique à mon besoin pour être intéressant… Tu peux le remplacer par un `backup.sh` dans lequel tu feras le montage de ton disque et le rsync. Sébastien
Re: udev: Lancer un script à l'insertion d'une clé USB
On 12/10/2023 11:38, Sébastien NOBILI wrote:
Le 2023-10-12 11:06, Erwann Le Bras a écrit :
Le 12/10/2023 à 09:06, fabrice a écrit :
Le montage automatique de la clé s’effectue après l’exécution de la
règle udev, même si je tente une commande mount dans le script,
/dev/sdd n’est pas encore disponible.
Une simple boucle d'attente?
do
sleep 5
while ! [ -d /dev/sdd]
Ma réponse précédente n'abordait pas ce point… je précise donc.
Ce n'est pas nécessaire. Ma règle udev est décrite comme ça :
```
KERNEL=="sd?2", ACTION=="add", ATTRS{vendor}=="...",
ATTRS{model}=="...", RUN+="/bin/systemctl --no-block start backup.service"
```
C'est quand un `/dev/sd*2` est créé et qu'il correspond au vendor/model de
mon disque que la sauvegarde est lancée.
Sébastien
J'ai tenté un sleep 60, la clé se monte automatiquement quand le script
ce termine.
J'ai tenté de mettre le processus en arriere plan avec un &
(KERNEL=="sd*", ACTION=="add", RUN+="/bin/bash -c
'/usr/local/bin/scanusb.sh %k &')
La clé se monte presque instantanément, le script est "tué"
J'ai pas encore testé le service. Je suis novice en systemd
et je ne sais pas non plus demandé a udev de monter la clé :)
Fabrice
Re: udev: Lancer un script à l'insertion d'une clé USB
Le 2023-10-12 11:06, Erwann Le Bras a écrit :
Le 12/10/2023 à 09:06, fabrice a écrit :
Le montage automatique de la clé s’effectue après l’exécution de la
règle udev, même si je tente une commande mount dans le script,
/dev/sdd n’est pas encore disponible.
Une simple boucle d'attente?
do
sleep 5
while ! [ -d /dev/sdd]
Ma réponse précédente n'abordait pas ce point… je précise donc.
Ce n'est pas nécessaire. Ma règle udev est décrite comme ça :
```
KERNEL=="sd?2", ACTION=="add", ATTRS{vendor}=="...",
ATTRS{model}=="...", RUN+="/bin/systemctl --no-block start
backup.service"
```
C'est quand un `/dev/sd*2` est créé et qu'il correspond au vendor/model
de
mon disque que la sauvegarde est lancée.
Sébastien
Re: udev: Lancer un script à l'insertion d'une clé USB
Le 12/10/2023 à 09:06, fabrice a écrit : Le montage automatique de la clé s’effectue après l’exécution de la règle udev, même si je tente une commande mount dans le script, /dev/sdd n’est pas encore disponible. Une simple boucle d'attente? do sleep 5 while ! [ -d /dev/sdd] ou qchose d'approchant Erwann
Re: udev: Lancer un script à l'insertion d'une clé USB
Bonjour, Le 2023-10-12 09:06, fabrice a écrit : Le montage automatique de la clé s’effectue après l’exécution de la règle udev, même si je tente une commande mount dans le script, /dev/sdd n’est pas encore disponible. Comment faire pour lancer la règle udev âpres que la cle soit monté ? udev intervient avant. Tu ne pourras pas. Mais tu peux très bien demander à udev de lancer un script qui va monter la clé et lancer ton rsync. C'est ce que je fais (lancement auto de sauvegarde à l'insertion d'un disque). Attention : si la commande est trop longue (et ce sera probablement le cas avec ton rsync), alors elle se fait tuer. Pour contourner ça j'ai créé un service Systemd et udev déclenche le lancement du service. Côté udev ça prend une fraction de seconde et ma sauvegarde peut prendre plusieurs dizaines de minutes. Enfin, plutôt que de te baser sur `/dev/sdd` qui est susceptible de changer, je te conseille de référencer ton disque par son UUID (via `/dev/disk/by-uuid/`). Sébastien
udev: Lancer un script à l'insertion d'une clé USB
Bonjour Je cherche a lancé lors de l’insertion d’une clé USB une commande de sauvegarde rsync à l'aide udev. Comme premier test, j’ai créé le fichier « /etc/udev/rules.d/cat /99-usb_scan.rules » contenant : KERNEL=="sd*", ACTION=="add", RUN+="/bin/bash -c '/usr/local/bin/scanusb.sh %k'" rechargé udev |udevadm control --reload-rules| La commande « udevadm test /dev/sdd » affiche bien « run: '/bin/bash -c '/usr/local/bin/scanusb.sh sdd'' » le script scanusb.sh contient : #!/bin/bash FILE="usb_scan.log" echo "** Scan - USB - $1 **" > /tmp/$FILE date >> /tmp/$FILE id >> /tmp/$FILE sleep 30 cat /proc/mounts | grep "sd" >> /tmp/$FILE sleep 3 echo "** EOF ** " >> /tmp/$FILE J'ai pas de /dev/sdd dans le fichier de log. Le montage automatique de la clé s’effectue après l’exécution de la règle udev, même si je tente une commande mount dans le script, /dev/sdd n’est pas encore disponible. Comment faire pour lancer la règle udev âpres que la cle soit monté ? Merci pour votre aide
