Replies: 6 comments
-
|
What should everything be |
Beta Was this translation helpful? Give feedback.
-
|
as with most code bits, it depends lolol. These SO posts have a good starting point to understanding, and not just the top comments have decent info:
I would say just using the following would be fine. Now, as one of the dudes in the 2nd link said on different linoox systems it wont work depending on how people have stuff installed but meh....... #!/bin/bashWe can also use the following, but it is less secure iirc but idk how much of this being less secure is bs..... #!usr/bin/env bash@thecoulter plz weigh in |
Beta Was this translation helpful? Give feedback.
-
|
did some edits to the issue bit so i dont have to create a whole other issue. Gonna also be putting this info in glyvemind |
Beta Was this translation helpful? Give feedback.
-
|
How about for Python and the various environments? It is typical to have several python versions on any given system. If you specify /path/to/this/python you might cause issues. The use of /bin/bash is problematic for Mac users. I can probably be convinced otherwise, but I think we should prefer /usr/bin/env unless a certain file is used almost exclusively inside a container and it is a high security risk (and if so, can we make it not be?). |
Beta Was this translation helpful? Give feedback.
-
|
yea i was thinking about us properly using conda for our python stuff instead of using a python venv but ngl unsure how useful that would be and how nice it would play with out stack plus wanted to do that in another ticket once we get the bash scripts normalized. That way our conda could force the python version and handle what pip does, but again im not super confident that this will play nice with our current stack (https://stackoverflow.com/questions/73846871/how-to-exchange-data-between-two-different-python-processes-of-different-conda-e is an example of something annoying we would probably have to do with conda). The biggest problem about not normalizing python versions is that some versions of python change how the code itself works. Think back to when we switched from Bash on mac should be easy enough. I am pretty sure that it is already within the OS and if it isnt one can use homebrew aka running Using |
Beta Was this translation helpful? Give feedback.
-
|
For Mac, there is a built-in bash, but it's an old version of bash. Yao ran into this. The version answering at /bin/bash was too old to run some of our scripts. And, while he could install another bash, he couldn't change the version answering at /bin/bash. So, unless there is a strong reason not to use /usr/bin/env, I think that is he way that is best for us to go. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
We need to normalize all of our bash scripts. This includes:
bashshabang, the file extension for these should be.bash). This can cause some messing with how the git history is tracked, so file extensions are not super high prority but we still need to hit thisreturnandexitwithin our bash commands.shellcheck --enable=require-variable-braces,quote-safe-variables,add-default-case <fileToLintHere>shfmt -i 4 -ci -fn <fileToFormatHere>Bug Description:
A recent bug caused by this was the
gems/tests/run_tests.shscript having a#!/bin/shshabang which caused it to not have the bashsourcecommand available to it. Furthermore, inconsistencies increases brain usage which is bad and makes scripts that would grab all specific files etc. to run tools on them more difficult.Additional context
Think of different shells as kinda like different programming langauges. They are not all interchangeable, so we gotta keep that in mind. If we just stick to
bashshells that use the baseline commands/progs we should be good. Getting a collection of all our scripts without shabangs would be good for someones first issue, actually changing them and ensuring the shabangs are correct is dependent on the devs skill levelInformation regarding shabangs:
Information Regarding
exitvs.returnreturnin our functions, and ngl we can useexitin our functions if the script is supposed to exit if a function fails but this pattern isnt very common. So let's just go forreturnon all our functions while usingexitto react to a failed functions return valueBeta Was this translation helpful? Give feedback.
All reactions