It's UWAweek 48

help2003/help4407

This forum is provided to promote discussion amongst students enrolled in Open Source Tools and Scripting.

Please consider offering answers and suggestions to help other students! And if you fix a problem by following a suggestion here, it would be great if other interested students could see a short "Great, fixed it!"  followup message.

How do I ask a good question?
Displaying selected article
Showing 1 of 564 articles.
Currently 4 other people reading this forum.


 UWA week 18 (1st semester, week 9) ↓
SVG not supported

Login to reply

👍?
helpful
1:47pm Mon 2nd May, Djimon J.
Edited: shortly thereafter

Can we use coloured text for any >&2 echo (stderr) text so that it's easily to see the difference between it and the output. My scripts will output any errors with the command line arguments, but will continue if it's still possible using the valid arguments supplied. This means I end up with multiple lines of output, but only one is the actual output of the program (the rest comes from stderr but is still shown on console).
For example for common_words, if it's called like ./common_words "a-valid-directory" -ntspeltwrongh notanumber where the directory is valid but the arguments are wrong, it will output this error to the user but continue assuming -nth 1, and produce an actual output after the error messages.

I found out that it's possible to colour text with echo -e "\e[32mSome coloured text\e[0m" which makes the output significantly easier to read, understand and format. So can we use coloured text for our output?

Also, detailed error messages make the code significantly longer than necessary, with about 70 lines solely for parsing the command line arguments. Without doing this, I was able to shorten the argument validation to about 15-20 lines with just checking 3 formats either 1 arg, -nth option, or -w option. However this cannot give any information about which arguments are invalid only that the script was called incorrectly. Would this be considered bad style and maintainability or would this be better since it gives useful information to the user, assuming it is done in an efficient and clear way (although it's still a lot of code).

The University of Western Australia

Computer Science and Software Engineering

CRICOS Code: 00126G
Written by [email protected]
Powered by history
Feedback always welcome - it makes our software better!
Last modified  1:17AM Sep 14 2022
Privacy policy