search

sunodo / sunodo

Sunodo monorepo
https://docs.sunodo.io
Apache License 2.0
21 stars 14 forks source link

sunodo shell should provide an option to define the shell to use #469

Open endersonmaia opened 1 month ago

endersonmaia commented 1 month ago

📚 Context

The shell that's called by sunodo shell is hardcoded to /bin/bash.

It should be possible to define another shell.

✔️ Solution

Default to /bin/bash and add a --shell argument to define a different one.

sundo shell --shell=/bin/sh

omidasadpour commented 1 month ago

It should be possible to define another shell.

Can you describe why it is needed ?

as far as I know this sub-command starts a shell in cartesi machine of application that is a docker container that has bash. So, why should we consider other shells ?

endersonmaia commented 1 month ago

It should be possible to define another shell.

Can you describe why it is needed ?

as far as I know this sub-command starts a shell in cartesi machine of application that is a docker container that has bash. So, why should we consider other shells ?

I'm working on a small image with busybox, and face the problem of not having /bin/bash in place.

I could fix it easily by creating a symlink, but It felt weird having to do this.

We could have a default and allow to change for whatever shell (busybox sh, /bin/sh, '/bin/zsh...) or at least document somewhere that the image needs a /bin/bash in place.

Also, my suggestion looks weird reading this afterward, this shell --shell repetition is odd.

omidasadpour commented 1 month ago

Also, my suggestion looks weird reading this afterward, this shell --shell repetition is odd.

could use shellpath arg.

I'll send a PR.

tuler commented 3 weeks ago

Why don't we provide an option to exec something in the cartesi machine, instead of having a specific command for shell? Something like sunodo exec instead of sunodo shell.

sunodo exec can be confused with sunodo run, but I think we can think about it.

An interactive flag may also be necessary.

omidasadpour commented 3 weeks ago

Why don't we provide an option to exec something in the cartesi machine, instead of having a specific command for shell? Something like sunodo exec instead of sunodo shell.

sunodo exec can be confused with sunodo run, but I think we can think about it.

An interactive flag may also be necessary.

U mean Something like this ? 

sunodo exec --command "ls -la"
tuler commented 3 weeks ago

I mean sunodo exec /bin/sh

endersonmaia commented 3 weeks ago

I mean sunodo exec /bin/sh

My worry with exec is the confusion with the docker exec, where it's expected that the command is going to be executed in an already running container.

tuler commented 3 weeks ago

I mean sunodo exec /bin/sh

My worry with exec is the confusion with the docker exec, where it's expected that the command is going to be executed in an already running container.

Yeah, but sunodo run is already taken for the node execution.

omidasadpour commented 3 weeks ago

I mean sunodo exec /bin/sh

I'm going to send a PR for it.

tuler commented 3 weeks ago

Is this customization really necessary? Can't we have a shell that we know will always be there? I want to minimize as much as possible new options and new commands. To keep sunodo as simple as possible for users.

endersonmaia commented 3 weeks ago

Is this customization really necessary?

I created it as a feature request. It's necessary for my use case.

Can't we have a shell that we know will always be there?

We could have this as a requirement somewhere. After we start using the cruntime (#455) we won't need this and we can control what's inside the main rootfs.

I want to minimize as much as possible new options and new commands. To keep sunodo as simple as possible for users.

I agree.

We need a better development workflow written down somewhere so that collaborators don't start working on things that were not discussed and got a tag or milestone that defines a issue as good-to-go.

tuler commented 3 weeks ago

We could have this as a requirement somewhere. After we start using the cruntime (#455) we won't need this and we can control what's inside the main rootfs.

So I guess we can wait until cruntime is ready, and not implement this.

We need a better development workflow written down somewhere so that collaborators don't start working on things that were not discussed and got a tag or milestone that defines a issue as good-to-go.

A simple label can take care of that.

tuler commented 3 weeks ago

A simple label can take care of that.

triage is a popular one. Meaning: "people, we need to discuss this further, before implementing it"