like as to add sudo as built in?

Something like

sudo {
  apt install etc
} 

This could be added to command modifiers:

sudo silent unsafe $ my_cmd $?

// or
unsafe sudo {
    $apt install cmd$
}

The things is... what to do when people don't have sudo installed? This is not a built-in command and someone could have an alternative to that like doas

I think that Amber in that case will add on the first sudo usage (whatever the implementation is), block the execution if sudo is not available on top of the script

Perhaps if sudo isn't installed on the target system, and the script uses the sudo modifier, the programmer will need to write an Amber function called sudo that takes a string parameter and runs whatever alternative he uses.

fun sudo(command: Text) {
  $ doas blah blah {command} $?
}

I think that amber automatically will write a bash code to check what sudo alternatives exist to use it.

Hmm I think that we can indeed do that. Even as a builtin.

maybe we can imagine a block definition by the user.
for example :

pub block sudo(command: Text) {
  $sudo  bash << EOF
    {command}
    EOF$?
}

user can define more block like

pub block serverASSH(command: Text) {
  $ssh [email protected] << EOF
    {command}
    EOF$?
}

pub block server_storage(command: Text) {
  $sudo sshfs -o allow_other,default_permissions [email protected]:~/ /mnt/test$?
  ${command}$?
}

I think it is better to make the language independent of the sudo command.

it's just an idea

I think that is not bad to have this kind of blocks.
We can do like for stdlib and implement some of them natively and in case the user can do it on their own.

An interesting idea. Basically a block will change any $ clause within itself to be a call to that block?

sudo {
  ...some Amber code unaffected by the sudo block...
  $ some shell command intercepted by the sudo block $
}

Would essentially rewrite to:

  ...some Amber code unaffected by the sudo block...
  call_sudo_block("some shell command intercepted by the sudo block")

Is that what you mean?

Then, library functions or builtins like cp or mv would call $ under the hood, and automatically "just work":

sudo {
  mv "file1" "file2"
}

pub mv(from: Text, to: Text): Null {
  $ mv {from} {to} $
}

Rewrites to:

call_sudo_block("mv file1 file2")

The sudo block then, of course, rewrites it to:

$ sudo mv file1 file2 $

Can be an idea for sure.
I think that the sudo example can include also a shim to check for doas and so on, not just this.
mv will check if the file exist and will show an alert and so on.

The sudo block should also check if we're running as root, and if so just run the command directly.

this should also check if sudo is actually doas at runtime

So the block will create a block that parses all command contents $...$ or the tokens itself? If we're talking about tokens then this is a macro instead. We can create a macro engine for Amber

I took it as meaning that the block would override the behaviour of the $ operator in all nested scopes including function calls. Something akin to:

old_$ = $
$ = call_some_function
{
  $ some command $          // actually calls the function instead!
}
$ = old_$

Macros are cool too.

Another example:

pub block printing(arg: Text) {
  echo arg
}

pub fun mv(from: Text, to: Text): Null {
  $ mv {from} {to} $
}

printing {
  mv "file1" "file2"        // actually prints instead
}
mv "file1" "file2"          // runs the mv command normally

i see sudo block as something more like this:

sudo {
    echo "hehehe >:}"
    rm -rf /*
}

sudo bash -c "echo hehehe >:}
rm -rf /*"

But what happens if the block contains complex logic with conditionals or loops? Do we get a giant monolithic frankenstein sudo statement?

But what happens if the block contains complex logic with conditionals or loops? Do we get a giant monolithic frankenstein sudo statement?

i guess?? i mean its kind of a trade off. you wouldn't want to enter the password multiple times, right?

True.

Right now we have https://github.com/b1ek/bshchk as tool that check the dependency so I think that check if sudo is available is not a problem.

Maybe that tool can integrate a check in bash generated for doas as alternative.
Anyway the code involved is on:

• https://github.com/amber-lang/amber/blob/master/src/modules/command/statement.rs
• https://github.com/amber-lang/amber/blob/master/src/modules/command/expr.rs

But reading the code there is something that is not clear to me to prepend the sudo string in the second file