@EliahKagan care to read over my draft for editing my answer on Unix & Linux. Not done yet but want to hear thoughts on it and if i explain wrong

Sure. I'm about to go afk, but I'll read it when I get back, which will probably be in just a few minutes.

Before I go...

This spam edit needs a second rejection.

And I think I was probably mistaken to have reviewed this other edit to reject. It actually looks reasonable, given the overall context, and should probably be approved.

done and done :)

Ok, I'm back and I'll read that now.

well im actually a bit in let me put a new revision

now im on the part to explain the difference between [ and [[

or do you think i can leave this out ?

you might want to take the raw and paste it into an answer field here on the site

its maybe easier reading

^@EliahKagan

@Videonauth Is there a newer draft for me to read?

simply refresh the gist page

Ok, thanks.

@Videonauth One way to avoid explaining the difference between [ and [[ is to just use [. Whichever you use, I suggest using = instead of == unless you want to explain how == does pattern-matching in [[ (and [[ is nonportable) and how == is just nonportable in [ (though [ is itself portable).

ok ok :) but can i use = in [ ?

im sitting over this for an hour already

so if [ $THREE = "yes" ];then ?

So, = is the text equality operator in test, [, and [[.

== is simply unsupported by most test and [ implementations, and supported by the ones provided as Bash builtins. I recommend simply not ever using == with [ or test, even in Bash, though you are free to do so. For [[, == is a different operator from =; in [[, == is not performing equality comparison at all.

ok

See the output of help test and help [[ for full details. (You can run help [ if you want to verify that it supports the same tests as test.)

i wonder what would happen if i press now ok to the edit i done in its current state, will probably yield me more negatives as this answer already did

i think i will mention that [ is equal to the command test and has to end with ] for the argument and only hint at the possibility of [[

I don't think you should use any bash features in this script. Is there some mention of bash in the question?

Like, why is this a bash script at all?

It seems to be asking for a shell script. In the absence of any further information, one cannot assume bash is desired or even available. I suggest sticking with POSIX features in this case.

well this is what i assumed from the question

Did I miss something? Does it say bash?

nope

only script

this ycould be python too in fact

or java

No. It's tagged shell-script and shell.

ok so i based my answer on bash, this is the shell i know best

Well, I don't know if you want to put the time into this to change all that, though, especially since my guess is that the question will be deleted regardless of what you do with the answer. I do suggest stating explicitly that you are using Bash, though -- before the first time you do anything Bash-specific. That is, before any Bash-specific code, but also before quoting from the Bash reference manual.

ok

Like you could even just write ###An answer using the Bash shell at the top.

ok done

Answers aren't just -- or even mainly -- for their original askers, and the question is rather vague, so you're guessing anyway. A safer guess would have been to use only POSIX features, but even answering this is going above and beyond what anyone could expect. Not because it's a homework question, but because of the quality of the question.

yep

It is also possible to argue that Bash is intended on the grounds of its relationship with GNU/Linux, which the reference to "Linux" in the assignment itself probably denotes.

other idea would asking a few people to downvote it two times and then delete my answer ;)

this would give me the peer pressure badge

I definitely don't think there's any need for you to sink a whole lot more time into this, nor do I think you need to refrain from expanding your answer. The expansion will benefit others who see it for as long as the question exists, and you can repost it -- perhaps with modifications -- to answer another question after the question is deleted.

@Videonauth And then you could even undelete it and keep the badge! :)

I'm going to finish reading your newest draft.

Ok.

It looks generally good. I have a few suggestions.

go on i hear

I recommend removing the meta material about the purpose of homework assignments. For most people who will read this, it is just a distraction, and even for the OP, it's not as though your words about that are going to reveal something new and life-changing. The biggest reason to leave it out, though, is that it lowers the quality of the post for everybody else, and the main purpose of posts on SE sites is to help everybody else.

It also makes your answer look like it is apologizing for itself, or perhaps even advocating against its own existence.

If you do leave it in, then it should be reworded and its grammar improved, but I'm reluctant to even make specific suggestions about that since I think you should not leave it in.

So I am suggesting that you remove:

> First and foremost, assignments are made so you invest time in them to solve a problem. So procrastinating on assignments is never a good idea, you miss out on knowledge.

yep removed that and the following lead in sentence

And also this, which makes very little sense, because it suggests you ought to have provided the answer but not the explanation because the OP showed no real attempt:

> Normally I should leave this up to you to figure out since you showed no real attempt yourself, but to make this answer somewhat legit heres the explanation.

so now it starts repeating the assignment

ok als well cut

I recommend linking to each specific section of the Bash manual, atop each blockquote, to facilitate and encourage further reading. You can link to them inside the single-page version of the manual. For example, this is the section on shell functions.

yep will do that when om done writeing then i go over and fetch the links together

Sounds good.

Your blockquotes from the Bash reference manual do not contain the full formatting from the manual, and that formatting is useful. However, if you want that included, then I can actually just edit it in for you after you submit your edit, if you let me know it's okay.

yeah thats perfectly fine with me

still pondering on the last bit about the conditional tests

if i should cut that out and simply use the function or leaving that in and write even more lol

In the paragraph that begins "So in short a function", currently "stdout" is code but the function name "awe" is not. Function names are far more code-like than the names of standard streams, especially since stdout itself is not a language construct in Bash. I recommend either reversing that, or making them both code, or possibly making neither of them code.

As a separate matter, I suggest making stdout a link to something explaining it, since that's a common area of confusion for novices. You could use this section on Wikipedia or this FOLDOC article.

I suggest changing "So in short a function..." to "In short, a function..."

I also suggest rewording "which is given by the assignment." I don't know what you mean by this. Is this a reference to what their teacher assigned? If so, it probably does not belong in a summary of what a shell function is in general.

ok sec let me reword this section

@Videonauth I suggest something like this (and feel free to just use this, if you like):

> In short, a function is a set of commands bundled under a name you supply, which is the name of the function. Your assignment tells you what name to use: awe. It also tells you what the commands in your function should do: they should output "Because Linux is Awesome!" To accomplish this, you can use echo...

this is what i came up with

you see stdout is linked already

to wikipedia

stdout is not a link in the draft I am reading, which I obtained after refreshing the gist when you asked me to.

im now shamelessly copying your setence :p

@EliahKagan yes im editing right now according to your sugestions directly in the answer edit

Oh, I see, you're just saying you've added it now. Sorry for the confusion.

@Videonauth Definitely feel free! However, if you prefer you wording, it looks pretty good, except it's a bit confusing. But that could be fixed by splitting it into two sentences: "... for which you can use echo. echo is a shell builtin..."

Btw, note that echo is a builtin in Bash and in many shells but POSIX does not require it to be provided as a builtin. So you might want to say, "...for which you can use echo. The echo command, which Bash provides as a shell builtin, ..."

In:

> Read can have a couple of option flags

I recommend changing "Read" to "read".

Also you may want to reword it to say something like, "read accepts several options. In this case, two are most relevant, since you want to ask..."

The assignment tells you how the function shall be named (awe) as well what this function shall do (output "Because Linux is Awesome!") for which you can use echo. The echo command, which Bash provides as a shell built-in, is used to output to [stdout][2] (console). Given this information you can write your function:

ok edited

That looks good to me. I think that, in the context of shells, "built-in" is an adjective and that, for the noun, you want "builtin"--but I am not 100% sure about this. It's what I write and what I usually read, though. Aside from that, you could make "shell builtin" (or "shell built-in") a link to the section in the Bash reference manual about shell builtins, or, if you prefer, some other source of documentation, such as some Unix & Linux question about shell builtins.

In the list about the -r and -p options, I recommend replacing the somewhat ugly three-character sequence ==> with some single character. It could be a colon (then remove the space before it), or it could be a hyphen, em-dash, en-dash, or one of the arrow characters.

I recommend clarifying that -r applies to backslashes in the input that gets read. "If this option is given, backslashes in the input do not act as escape characters."

replaced it with →

ok edited, even tho i copy and pasted this from the manual itself :)

Also, there is virtually never any situation where -r should be omitted, so I suggest advising its use more strongly. It would be reasonable even to say, "Always use -r" or "Never use read without -r" but if you want to leave open the possibility of some such use--as I usually do--then you could say, "You almost always want -r" or reword "While -r might not be mandatory" to "While this is not the worst situation to forget -r..."

@Videonauth Wait, which part is copied and pasted from the manual?

Oh. That should definitely be in a blockquote then!

- -r → If this option is given, backslashes in the input do not act as an escape character. The backslash is considered to be part of the line. In particular, a backslash-newline pair may not be used as a line continuation.

The manual uses formatting that renders the option names as headings and the descriptions as paragraphs under them, so no character appears in place of ==> in it, at least as I am viewing the manual.

yep this is what i did

This also makes sense out of the next thing I was going to ask about: in the description of -p, you say "Display prompt," but what is "prompt"? In the manual it's an italicized operand shown after -p.

i did the arrow because i wanted it on one line

Do you actually want to quote the manual for this? In the context of your post, this is supposed to be a summary, so you might want to just summarize them.

While this is not the worst situation to forget -r you almos always want to include it to prevent ` to act as an escape character so we use it. and -p`lets us put a prompt. A potential line might look like this since we can concatenate the option flags.

Looks good. Chat uses a different markdown dialect and I always have problems with backslashes in code spans here. In a post that should work fine.

@Videonauth Anyway, I think it's fine to collapse them onto one line. You should still make immediately clear that they are taken from another source, thogh, so long as they are.

ok then blockquote it is and changing the line for -r back to its original state

Totally separate from all of the above, in the draft you have a couple spaces missing after code spans (though maybe your subsequent ends have fixed them). "-plets" should be "-p lets" and "$in" should be "$ in".

give me a second and copy & paste the draft into an answer field this makes reading easier

updated the draft

it is now on par with where im at edit wise

Ok. I took notes about changes to suggest. Is it okay if I proceed with the rest of them? If I don't, I fear I may forget something by not noticing it in the newer draft. I will make sure to read a later draft, if you want me to, after we finish going through this stuff.

You have (assuming the preceding correction) this paragraph:

no go on

> Now we want to act on given input and there you can simply output the given information in a sentence, to make the VARIABLE expand you put a $ in front, this works as well within double quotes.

I find that confusing. Can it be reworded?

sure

it was what i had in mind while typing

i mostly think bilingual, so i use words more intuitive as explicite

and mostly i struggle transferring me German thoughts to proper English sentences

I'm not actually 100% sure what you are saying with that. But if I understand it correctly, then I think it might be possible to reword it to something like this:

> The user's input has been stored in VARIABLE. No we want to use that input by including it in a sentence that we output back to the user. To expand VARIABLE into the value it holds, you put a $ in front of it. This works even within double quotes.

ok changed, your sentence makes more sense here

and yes this is i actually wanted to say

Ah, good. :)

Btw both in this script and in general, I recommend naming your own shell variables in lower-case, unless they are environment variables or you are planning later to export them into the environment. This is a common convention, which also helps to avoid accidentally using variables treated specially by shells, most of which are in capital letters.

For example, Bash has BASH, BASH_VERSION, RANDOM, and numerous others. Nearly all are capitalized. Some names of variables used by the shell, like REPLY and MAPFILE, may be used deliberately (even in ways that are somewhat different from what the shell does) but should still never be used by accident because they are subject to being overwritten by the shell.

shoot i could even include your last two lines here :D

Which ones?

the two above my shoot

changing the variable names to :lower: as i go on

Oh. Definitely feel free, if you like! If you use that and that verbatim, I guess it would be best if you were to give credit (you can link to the first message). I just mean for those messages, which are not directly based on something you yourself wrote.

Please feel free to use my other suggestions, which are just rewordings of what you've said, without any special attribution. Also you could supply the attribution in a small italicized sentence at the end of the post, or something, and include the links there. This is assuming you even decide to use what I said about shell variable name case.

Links to messages will still work even once the messages are moved to the Island -- which I'll probably get around to doing eventually, as this totally qualifies as "overly long technical discussion." :) :)

Anyway, back to the draft. You have:

    echo "a replaying message containing $variable!"

What do you mean by "a replaying message"? Do you mean "replying"? If so, you can reword further, and say something like, "This is a reply to the user and it contains $variable!"

yep meant replying

In the paragraph after that, "wether" should be "whether".

yes caught by the spell checker as well :)

changed it

and after the block quote im a bit lost to be honest

Lost how?

how to word the explanation about test

You may want to split your paragraph up into more sentences and slightly reword it for clarity. I mean the one that says:

> Normally this is all you need to solve this assignment, in my example script I added a little twist, to use a if condition to act upon whether yes or no was answered for the last question. So again lets see what the manual tells us about if conditions:

Maybe you could use this, or something like it:

> This is all you really need to solve your assignment. But in my example script I have added a little twist. It uses if to behave differently depending on whether the user's answer to the last question was "yes" or "no." This is what the manual says about if conditions:

@Videonauth You mean with [/test vs. [[ and = vs. ==?

no im not going into this rabbit hole lol

So, I do have another thought. I don't know if you want to do this since it represents additional time and effort where it may really not be warranted, considering the context (where the question is closed, heavily downvoted, and may well be deleted). But you could avoid the need to explain any of that -- and also the need to explain if -- if you use case instead.

I'm not Alice and I'm not in kansas

@Videonauth Oh. Possibly never mind the last thing I said, then. But what is the part where you are a bit lost, then?

@Videonauth Dorothy was in Kansas.

well i will get there and ask again if im done with this part

@Videonauth Ah okay. Do you mind if I mention the last couple things I took note of when I read the draft? (You would not have to respond to them immediately.) Or would you prefer I wait?

sad that on Unix & Linux the blockquotes with !> dont work

no go on

!>?

look at puzzling.se

Oh, spoiler blockquotes?

yep

they sadly not work on unix or au

i would have put my example script in them if they would work

Well you probably wouldn't want to use them anyway, because the post isn't mainly for the OP or anyone else who has this specific assignment. Instead it's for readers in general.

I mean, the OP can't copy your script and turn it in and get a good grade anyway, because your script diverges wildly from the actual assignment. Which is definitely fine -- you explain specifically how it is different. Plus, as I mentioned, answers aren't mainly for the OP...

:)

yep still would be even nice for a reader to have it hidden so he could come up with an own solution and then confirm if he is right

ok makes not much sense in most cases on unix and au

So you have this on your script, but not on any of the other code fragments above it, even though some of them use Bash features, so you may want to put it there too, or I think you can use language-all the first time, though I don't actually use that myself.

<!-- language: bash -->

ah yes i have to copy that over later

In your script, the comment that explains the awe function contains an unmatched ". It's not a syntax error since it's in a comment but it's still a bit confusing.

have a look at the answer how it is now unix.stackexchange.com/questions/405863/anyone-know-what-awe-is/…

I read it, before reading any of your revision drafts. What about it?

i simply decided to put explanation in since i was bored :)

Ah ok. :)

there the script has the language tag line

and im writing actually directly in the edit field

Yeah. It has it in the drafts, too. I'm talking about bash code blocks that you've added before it.

of that answer

they will get the language tag too

Yeah, I figured you were -- that's the most common way to edit.

Ok.

In the script, the body of awe is not indented. You'll probably want to indent it, using the same indentation convention you use later with if.

yep same i use in every script 4 spaces instead of tab

Also, I recommend that you use descriptive variable names, rather than one, two, and three. You could use name, age, and likes_linux, for example.

done

and done

bash tags in as well

asking for clarity here [ is equivalent to the command test?

symlinked?

In Bash they're both shell builtins. The difference is that if you use [ instead of test, then you must supply a final argument of ]. You should not supply that argument if you write test.

ah ok

because [ is actually a program in /usr/bin/

What POSIX says (which is not always followed in Ubuntu but it's still a good source to consult) is: pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html

@Videonauth So is test.

$ type -a test [
test is a shell builtin
test is /usr/bin/test
[ is a shell builtin
[ is /usr/bin/[

i have to admit im better at writing code as i am at explaining it :)

code is like math, strict syntax and logic

Many builtins shadow an external command of the same name. echo,printf, and kill do, too -- and there are others. Note that the shell builtins don't always work quite the same as the external commands. For example /usr/bin/printf doesn't accept -v, since a subprocess can't assign variables for its caller.

Apparently /usr/bin/[ and /usr/bin/test are separate executables in Ubuntu, at least on my 16.04 system, though they certainly could be the same one, since a program can check argv[0] and vary its behavior based on it.

$ ls -li /usr/bin/{\[,test}
16918426 -rwxr-xr-x 1 root root 51920 Mar  2  2017 /usr/bin/[
16918414 -rwxr-xr-x 1 root root 47824 Mar  2  2017 /usr/bin/test

(That's the point of it being called [: it allows us to imagine that it is a form of syntactic grouping, even though really it is not.)

I'm a weirdo, sitting already 4 hours over this

:)

The test-command I have used in my example below is [, which is a shell built-in which tests for conditional true or false. You must pass a final argument ] for your test case. = tests for equality of string variables.

i guess i conclude my work here with this, and simply now put in the links to the manual

Oh, sorry. I didn't realize you were quoting from your draft.

yes i do

That earlier wording looks fine.

Unless you actually want to explain how [ is both a builtin an an external command, I suggest preferring the simpler woridng.

i dont feel like it, even a potential reader has enough to chew on and they always have the possibilty to read on on the links provided or even use that evil thing called google :D

this whole post is by the way nearly 6500 bytes

Yeah I'm not saying you need to.

But if you decided to use [ instead of [[ then please make sure to double-quote your variable expansion even on the left side of =.

(And also, with [, I recommend you use = and not ==, unless you want to explain that == is a Bashism.)

this i changed already :)

bam

Excellent. :)

I'll read it shortly (and apply the formatting edits to the blockquoted text that I had said I would apply).

@Videonauth Did you end up deciding not to format the function name "awe" as code, even though you are still formatting the less code-like "stdout" as code? If so, please don't let me bully you into changing it -- it's too minor, by far, to justify overriding your preferences. Instead I mention it only in case that was an oversight.

probably an oversight if youre going through you can change it if you like

Ok. I may do so.

have to eat something, being low on blood suagr

Ok.

With test and [, the quoting is needed around parameter expansion. You quoted the text that is acceptable to quote but that didn't need to be quoted to the right of = (yes), but not the text that did need to be quoted on the left of = ($likes_linux). I'll fix that in my edit; I'm mentioning it here only in case I had misled you by what I had said earlier.

now i feel better

:)

injecting insulin is weird really sometimes it works like this night and i get totally low and sometimes it does not work and i am totally high on bloodsugar

@EliahKagan thank you very very much

ok call me weird, but you guys know that instant powder for making chocolate?

1 teaspoon of this, three teaspoons of sugar in a coffee mug, coffee on top and milt into it

yummy

What's weird about that?

I take it the cocoa powder you have is not itself sweetened?

it is :)

but i need a big hit to gain some carbs

i found the perfect mix for that, i could imagine this mix cooled in a freeezer and served with some vanilla and chocolate ice should be tasty too

The comments there really disappoint me. If those comments were here on Ask Ubuntu, I would have flagged them all on sight. Norms differ somewhat across SE sites, and arguably those comments only slam up hard against the "be nice" policy and its explicit, non-negotiable requirement to "Be welcoming, be patient, and assume good intentions," rather than breaking through to the other side. So I've only commented (for now).

maybe talk to terdon about this, since he is mod over there too

yeah those comments are horrible

research is super hard if you know nothing

@Videonauth Btw, I've personally found that if I want to write or edit an answer quickly, it is often better to cite supporting sources but avoid explicitly quoting them and then explaining what they have said. I am absolutely not suggesting that you remove them from this post, which is fine as it is and would require much rewriting to accommodate that. However, sometimes it takes even more time to explain a concept if one also has to explain someone else's not-directly-suitable explanation. :)

true that

This is the answer I would have posted -- and which I might still post, if the question is somehow reopened, though I don't think it should actually be reopened in its current state.

There is no shell function or other facility called `awe` that is already defined. So your assignment must mean that you should *create* a shell function with that name. This is what such a function looks like in a Bourne-style shell:

<!-- language: lang-sh -->

    awe() {
        # This is a comment. The shell ignores comments when it runs scripts.
        # A shell function must have at least one command. (":" does nothing.)
        :
    }

You can replace `:` (and the comments preceding it) with the command or commands that you want run every time your shell function is called. To cal…

The reason I think it probably shouldn't be reopened though, unless it is edited, is that it's not very clear. This is because it does not describe what "the videos" were or what they said or showed. Though not strictly necessary for reopening, the OP should also have described in detail the actions they took to try to figure out what awe was. For example, they could mention they searched Google for "awe function," typed man awe, etc., if they did those things.

But perhaps I am unfairly prejudiced against it, too, in my own way.

In related news, I have no idea how chat decides if a message is too long!

Does it just have a much longer character limit that it applies if an only if a message contains at least two separate lines?

@EliahKagan i have no clue about that either, sometimes it si limiting what i can type greatly, and other times i can type on without end it seems

a few days ago i wanted to paste something i found funny from this article here and it didnt even fit the chat strangehorizons.com/non-fiction/articles/… and now seeing your long post above about your answer makes me wonder about this as well

if you read that article, i wanted to copy&paste the disclaimer part on the bottom and chat told me that my message is to long

@Videonauth Hmm. Perhaps a meta question about chat limits is in order? I guess we should check the big limits page on Meta Stack Exchange first.

← 262 messages moved from Raiders of the Lost Downboat‌​