Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

POSIX compliance #927

Open
OH-AU opened this issue Feb 26, 2019 · 4 comments

Comments

Projects
None yet
4 participants
@OH-AU
Copy link

commented Feb 26, 2019

In _extras/guide.md you suggest "Stay within POSIX-compliant commands" and helpfully give an example, however no assistance/referral is provided to check compliance. Having used various UNIX and UNIX-like operating systems, I couldn't tell you if a command I regularly use is POSIX complaint or not. The closest related issue I could find was #708 which asks for assistance in auditing. Perhaps the guide could be updated with a reference to:

  1. https://pubs.opengroup.org/onlinepubs/9699919799/idx/utilities.html
    Unfortunately, this doesn't cover bash itself. So also include a reference to:
  2. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_01

Perhaps something like; You can check for POSIX compliance for the shell here and command line utilities here
Thanks.

@colinmorris

This comment has been minimized.

Copy link
Contributor

commented Feb 28, 2019

Great point. I agree that, as it currently stands, this piece of advice is not very helpful. Even with the additional links you suggest, I think it would still be a little unclear (i.e. it's not clear the spirit that's motivating this rule, or what specific actions instructors are expected to take in response to it).

This is somewhat related to our ongoing discussion at #798.

I wonder about deleting this advice and replacing it with a section with some more informal, general advice about cross-platform issues and consistency, basically stuff like:

  • Where possible, try to use commands that work (and do the same thing) on all platforms. We've aimed for this in the examples given in the lesson.
  • Try to avoid teaching features that are specific to a particular operating system or shell dialect (unless all learners are using it?). For example, ____
  • You may still encounter some scenarios where a command fails or gives different results for certain learners according to their system's configuration. It's worth explaining to learners that there are some slight differences between Bash shells on different systems, but try not to dwell on them, or get bogged into technical explanations for why these differences exist.
  • [Some practical advice for powering through these hiccups during a workshop? e.g. if you have a minority of learners using system Y, you may want to seat them together so they can help each other out?]
@gdevenyi

This comment has been minimized.

Copy link
Contributor

commented Mar 11, 2019

+1 for enhancing that in the instructor's guide

We still have the issue of what to do with the lessons themselves though...

@OH-AU

This comment has been minimized.

Copy link
Author

commented Mar 13, 2019

Thanks for the comments - the bash conversation you linked to covers a number of related matters. I'm for @colinmorris 's suggestion of making it more generalised - most systems I use default to bash as the shell and the course is largely based around that presumption anyway (take the tab completion section as an example - that's not going to work as documented in ksh, or csh for that matter). And every system has their own custom alias' for common command so I think best effort, generalised as suggested above is reasonable and hopefully any major issues would get picked up on review when commited?

@drj11

This comment has been minimized.

Copy link
Member

commented Mar 22, 2019

I would avoid removing the note about POSIX compliance but would support adding a note about the motivation: "Where possible, try to use commands that work (and do the same thing) on all platforms" (quoting @colinmorris above).

I think both are required: Yes, we are trying to use commands that work on all platforms; and, as a practical guideline, we therefore prefer teaching POSIX compliant commands and examples.

At least we can start from there and add links to the relevant POSIX specifications and guides on how to comply. From a personal perspective I have no way to test if commands work on all platforms, as I only use shades of Unix, but at least I can read the POSIX specification.

@gdevenyi gdevenyi changed the title POSIX compliance in instructor guide POSIX compliance Apr 18, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.