Skip to content

Conversation

naltun
Copy link
Member

@naltun naltun commented Mar 7, 2021

Pull Request Details

Description

This PR replaces the Bash scripts with POSIX sh scripts.

Related Issue

This is to address PR #100.

Motivation and Context

Bash inherently has portability problems because it breaks POSIX compliance. Upgrading our shell scripts to be POSIX compliant will help with portability and drawing in new users.

How Has This Been Tested

TODO

Types of changes

  • New feature (non-breaking change which adds functionality)

Checklist

  • My code follows the code style of this project.
  • My change requires a change to the documentation.
  • I have updated the documentation accordingly.
  • I have read the CONTRIBUTING document.
  • I have added tests to cover my changes.
  • All new and existing tests passed.

These changes are unverified/untested. This is the next TODO item.
@apotheon
Copy link
Member

apotheon commented Aug 9, 2021

Does this need to be reorganized into a series of smaller pull requests, perhaps one file at a time, to ensure that they can be individually checked for correctness and merged before continued development leads to conflicting changes? Perhaps too many changes in a single commit will result in "race conditions" with commits for feature additions.

@SamuelMarks
Copy link

Actually it looks pretty trivial to me, and great to see folks actually caring about POSIX compliant shell scripting

(FYI: I'm an outsider not a mod)

for filepath in $(find "$DIR" -maxdepth 1 -name '*.kaos'); do
filename=$(basename "$filepath")
testname="${filename%.*}"
out=$(<"$DIR/$testname.out")
Copy link

@dumblob dumblob Oct 22, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't this be POSIX-compliant? I don't think cat is needed, but I didn't look it up in the spec...

Edit: Needless to say using cat here is always better because of better error handling. So this is just my thinking out loud.

I've checked it and the POSIX manual isn't explicit about this being disallowed or "non-POSIX" but e.g. dash doesn't seem to do the right thing, so I suppose it's definitely not portable and probably generally not considered POSIX compliant.

So thanks for spotting this (I myself wouldn't use $(<... because as I wrote above - error handling is better with cat).

#!/bin/sh

DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" >/dev/null 2>&1 && pwd )"
OSTYPE=$(uname --kernel-name)
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

testname="${filename%.*}"

if [[ "$testname" == "exit_"* ]]; then
if [ "$testname" = "exit_*" ]; then
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is weird - can a file exit_* actually exist? Or is it a forgotten "stop iteration over an empty list" relic before for filepath in $(find "$DIR" -maxdepth 1 -name '*.kaos'); do was introduced (instead of presumably for filepath in exit_*; do)?

valgrind --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=20 --track-fds=yes --track-origins=yes --error-exitcode=1 chaos -c $DIR/$filename -o $testname || exit 1
elif [[ "$OSTYPE" == "darwin"* ]]; then
/tmp/DrMemory/bin64/drmemory -no_follow_children -exit_code_if_errors 1 -- chaos -c $DIR/$filename -o $testname || exit 1
if [ "$OSTYPE" = "Linux*" ]; then
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above - this doesn't seem to do what was intended...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants