Force Bash and/or Sh shell on remote host?

Hello, I need your opinion and expertise in this case. I like to know if my approach to solve the problem is a good idea or not. We have two issues about the problem that the shell (fish & hetzner) on the user's remote server does not support our (bash/sh compatible) commands. <https://github.com/bit-team/backintime/issues/1905> <https://github.com/bit-team/backintime/issues/1745> Beside this issues I also discussed several approaches to a solution in the German Debian forum. <https://debianforum.de/forum/viewtopic.php?t=190714> First of all it is not possible to support "exotic" or all kinds of shells. My solution would be to force the bash and/or sh shell on the remote host using a command structure like this ssh user@server bash -c "foobar" If "bash" is not on the server there will be a clear error message we can redirect to the users. And when setting up a new SSH backup profile several checks are done on the remote server. Checking the availability of bash/sh shell could be one of that checks. Converting our inline shell commands to POSIX conform ones is not a solution. Not all shells in the wild are POSIX conform. To my knowledge most of the inline shell scripts used by BIT are bash conform. Not sure if sh would do it, too. Because of that I would prefer to force bash only in the beginning until we tested everything with sh, too. Regards, Christian

Dear Christian, I don't think BiT should support all the shells out there, but at least removing "Bashisms" would be helpful. Most of the Linux distributions ship dash which is basically "sh" of this era. If our scripts can conform to sh, I think we can alleviate most if not all the problem related to this. Converting the scripts shouldn't be hard. "shellcheck -s sh $FILE" would do. I'll try to look at it if my time allows, but no promises. Cheers, Hakan On 11/27/24 2:31 PM, c.buhtz@posteo.jp wrote:

Hello Hakan, thank you for the reply. Am 27.11.2024 13:55 schrieb Hakan Bayındır:
Most of it are inline shell code used with ssh all around in several py files. But it is not only about which shell syntax we use. It is about to force that shell on the remote server. It won't help to have dash/sh code if fish is running on the remote host. Regards, Christian

Hi Christian On 11/27/24 4:27 PM, c.buhtz@posteo.jp wrote:
You're right. However dash is generally a "system shell", so it's mostly bundled to run the system tasks (cron, boot processes, commands called by init system, etc.) so, user might be logging into a fish environment, but we shall have dash 99% of the time. So, it becomes a matter of switching to that shell. I don't know the commands in the source code (sorry for my laziness), but calling a command with "sh -c" allows us to run any command via dash and return back (e.g.: sh -c "echo Hello World!"). Maybe we can verify that we have bash or dash via checking where /bin/sh points and call the commands via "sh -c" explicitly to force our environment. Running "sh -c" looks like the environment is also inherited into the current session, so we can operate like nothing happened. Hope this is useful for you, Cheers, Hakan

Dear Christian, I don't think BiT should support all the shells out there, but at least removing "Bashisms" would be helpful. Most of the Linux distributions ship dash which is basically "sh" of this era. If our scripts can conform to sh, I think we can alleviate most if not all the problem related to this. Converting the scripts shouldn't be hard. "shellcheck -s sh $FILE" would do. I'll try to look at it if my time allows, but no promises. Cheers, Hakan On 11/27/24 2:31 PM, c.buhtz@posteo.jp wrote:

Hello Hakan, thank you for the reply. Am 27.11.2024 13:55 schrieb Hakan Bayındır:
Most of it are inline shell code used with ssh all around in several py files. But it is not only about which shell syntax we use. It is about to force that shell on the remote server. It won't help to have dash/sh code if fish is running on the remote host. Regards, Christian

Hi Christian On 11/27/24 4:27 PM, c.buhtz@posteo.jp wrote:
You're right. However dash is generally a "system shell", so it's mostly bundled to run the system tasks (cron, boot processes, commands called by init system, etc.) so, user might be logging into a fish environment, but we shall have dash 99% of the time. So, it becomes a matter of switching to that shell. I don't know the commands in the source code (sorry for my laziness), but calling a command with "sh -c" allows us to run any command via dash and return back (e.g.: sh -c "echo Hello World!"). Maybe we can verify that we have bash or dash via checking where /bin/sh points and call the commands via "sh -c" explicitly to force our environment. Running "sh -c" looks like the environment is also inherited into the current session, so we can operate like nothing happened. Hope this is useful for you, Cheers, Hakan
participants (2)
-
c.buhtz@posteo.jp
-
Hakan Bayındır