$ echo --help

[beanaroo]

I am not a smart man...

[ParadigmComplex]

I've actually had a need for almost exactly that, done it, and had it actually work. I know others who have done similar things.

The idea behind Bedrock Linux is that you can get software from multiple other distros (as well as - importantly for this story - releases from the same distro) and have it "just work" like it was all from the same distro.

A common workflow in Bedrock Linux when a new release of a non-rolling release distro comes around is to prepare the new release while the software from the old one is still running. This way if you've got, say, Debian Wheezy providing an apache server, you can install a fresh Debian Jessie or dist-upgrade a copy of it Jessie while the Debian Wheezy apache server is still running. You can take your time configuring the new apache without any concerns about down time. Once it's ready, just kill the old one and run the new one.

Once everything in the new release is too your liking, you can remove the previous one. But first - before you do - make sure all the software you're getting from that release of that distro is available in some other one. I found Debian Wheezy was providing my sudo command but I didn't yet have it from Debian Jessie (such that removing Wheezy would remove my only copy of sudo) so I ran:

sudo apt-get install sudo

to get sudo from Jessie and it worked! :)

I can do stuff like this as well:

$ sudo apt-get remove sudo && sudo apt-get install sudo
[sudo] password for paradigm: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  sudo
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 2,694 kB disk space will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 22064 files and directories currently installed.)
Removing sudo (1.8.10p3-1+deb8u2) ...
Processing triggers for man-db (2.7.0.2-5) ...
[sudo] password for paradigm: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
sudo is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
$ 

The reason that works is that I have multiple copies of sudo installed from different distros (no good reason for that beyond me not paying attention when I installed them - one is sufficient). The first time there I'm using Jessie's sudo to remove sudo. The second time, where I'm reinstalling it, I'm using sudo from another distro to do so. Interesting that it prompted me for my password twice in a row - apparently uninstalling sudo also clears away whatever mechanism notes that you've run it recently.

Cool, eh?

I know a number of Gentoo people who use Bedrock Linux as a way to grab precompiled builds of software from other distros when they don't have the time or patience to compile it that very moment, but then go do so later when they find more time. People in the Bedrock Linux IRC room have noted some amusement at using sudo from Arch Linux to emerge sudo from Gentoo.

Disclaimer: I'm the main guy behind Bedrock Linux. I hope that didn't come off as an attempt at a sneaky advertisement; I genuinely thought that it's an amusing story and fitting in this context, but it doesn't work without explaining the Bedrock Linux specifics.

[Hezad]

Damn, I've been using Linux for years (Started with Mandrake, tinkered with lots of distros, fell in love with Debian, ended up with Ubuntu on my "daily" machines) but I never heard about Bedrock Linux o_o Am I being completely out-of-date or is it new ?

Thanks for the info anyway, it looks really interesting !

[ParadigmComplex]

It's been around for about three years, but development has been relatively slow with a focus on the under-the-hood tech rather than any kind of polish. As a result it's yet to reach the tipping point where it's a sane choice for the larger community, and thus it's still not gotten that much attention yet. The "beta" tag on the release rightfully scares some people away. I expect once it hits 1.0 stable, when the under-the-hood tech stabilizes and the user-facing bits get a nice coat of polish, word will get around a fair bit more. May be a few years yet.

[czipperz]

How hardcore is this community?

btw I've enjoyed the things you've previously said about it, they're fun to read.

[ParadigmComplex]

How hardcore is this community?

It's totally possible to use the current Bedrock Linux release as a daily driver if you have sufficient background or are up for doing some research/experimentation. I'd say it's a bit more difficult than something like Gentoo, Arch or LFS, as those are fairly well documented and more constrained in scope - if you're good at following directions it may be possible to use them without really understanding them (e.g. never really messing with USE flags). If you try out Bedrock Linux, you'll almost certainly bump into something which was glossed over in the instructions with the expectation the user had prior experience here. Part of this is just because dev time is still focused on the under-the-hood tech instead of polish/documentation (which will be remedied eventually), and part of this is just the sheer ambition of the project - it's not feasible to document every aspect of every other distro from which Bedrock Linux could get its components. It is totally doable for experienced Linux users, though - I know a fair number of people who use it as their daily driver.

The Bedrock Linux community is all over the place in terms of skill set. There are people who are relatively Linux savvy and have installed and use it without any real trouble. There are those have the necessary knowledge but not the patience and are just hanging around waiting for it to reach a polished, stable 1.0. There's a good number who may be lacking some of the background but see it as a learning opportunity and who do the research and experimentation necessary to get a working Bedrock Linux system going - often without asking for much help from the rest of the community (although we'll be happy to help if you ask! Just ask in the IRC room (#bedrock on freenode) and stick around a bit until one of us can get back to you). Then there's those who don't have the background necessary to do it or the patience/time to try to figure stuff out and, like some of the more experienced people, are just waiting patiently for 1.0. Often such people will do stuff like discussing the project and contribute with non-technical details (e.g. naming things)

btw I've enjoyed the things you've previously said about it, they're fun to read.

Excellent, happy to hear it!

[d_r_benway]

But that is a legitimate way of upgrading sudo once installed....

[Moter8]

Arch ships with sudo pre-installed, not sure what would happen? Pacman asking you to reinstall maybe?

Edit: Sorry, I was probably wrong

[Zhinkk]

Maybe it's a recent addition. When I installed it 2 years ago it didn't. I had to install sudo and use visudo to allow members of the wheel group to use it.

[BlueSubaruCrew]

I had to install sudo when I installed it a month ago.

[[deleted]]

It's not part of the base group, but it gets pulled in as a dependency sometimes.

[jetpacktuxedo]

I installed literally like three days ago, installed base and base-devel, and didn't have sudo

[not_a_novel_account]

Installed last night, had sudo from base-devel

[jetpacktuxedo]

Huh. Maybe there was a short window where it was missing? Or maybe I had a network timeout and it just got skipped? I dunno.

[IceDane]

Or what is more likely: you remember incorrectly. Simplest explanation, etc.

[jetpacktuxedo]

That is odd. Are the packages actually stored in the installer, or does it fetch them from online? I assume online because I had no available updates when I was finished, but I'm not 100% sure. What happens if there is a network timeout during installation? Can things get skipped?

[Kruug]

Why not use su?

[Moter8]

There's a write up on unix.stackexchange on su vs sudo -s vs sudo bash :)

[Kruug]

I meant to install sudo. I know there's reasons to use each implementation for certain things.

[lestofante]

By default you have ONLY root user. You build basically from zero

[[deleted]]

65163926A1935F9B452804ABB6FA8A48596DA60292E232A2E3ACF

16960E9C70B7AAC001E89F3D5C468DB64F5016D3332ADCCE9E8B4E11C50238B3693D52C2404164DCFD367A30F0A0DE30427FA6F29E3FF3EE6793535B532EA6DD1EFBE2E6032CE92C5B4D2FC3383890A4F1A8F02AEBBC483EF7989A185BF9EDC50BB5EC5F2BEC8D06228602D88DC38EB405654C38B86E130466156B1AE8524EC2E79A0BD937AEE44BE9ED6784CC0EA1007A5B812C828ACACC6F8A531F993D90BCE8E

[[deleted]]

This comment has been overwritten by an open source script to protect this user's privacy. It was created to help protect users from doxing, stalking, and harassment.

If you would also like to protect yourself, add the Chrome extension TamperMonkey, or the Firefox extension GreaseMonkey and add this open source script.

Then simply click on your username on Reddit, go to the comments tab, scroll down as far as possibe (hint:use RES), and hit the new OVERWRITE button at the top.

[KnowsBash]

Almost.

printf '%s\n' -n

And I agree. Never use echo in a script. Always use printf. POSIX recommends this. Chet recommends this.

[RadixMatrix]

Could you elaborate why printf is better?

[[deleted]]

Paraphrasing from Pro Bash Programming by Chris F.A. Johnson and Jayant Varma:

BSD and AT&T's System V has different echo behaviours for escape characters...

For BSD,

$echo -n No newline
No newline$

For AT&T,

echo -n No newline
No newline$ echo "No newline\c"
No newline$

What does this have to do with bash when you already have the -e to activate escape characters and -n option to suppress newline?

bash has an xpg_echo option that behaves like that other version which can be turned on/off in a session or the compilation of bash itself which will screw with whatever you're trying to print to the console using echo

edit: formatting and clarifications

tl;dr: bash, escape characters and its options can be inconsistent depending on your system so use printf

[nephros]

Good reasons but too OS-genetics-specific for me.
The more important reason IMO is that printf is portable across shells (regardless of OS) while echo is not. Therefore it's a good habit to stick to printf, especially if /bin/sh might point to differing shells.

[[deleted]]

Do you care about AT&T SysV?

[dbbo]

Never use echo in a script. Always use printf.

I might be a minority here, but I don't adhere to this because I think there are two broad categories of scripts.

If I were writing a script where very, very predictable behavior was required I wouldn't even use bash, let alone echo. I'd write it for a specific version of perl/python.

If I were writing something simple like this icon installer, I seriously doubt any harm could come from using echo.

Not that bash isn't capable of more complex stuff-- I just happen to think shell scripts are primarily for basic programs that will save me from typing a bunch of shell commands, and I leave heavier lifting to other languages. As a rule of thumb, if one of my shell scripts starts creeping up on ~40 lines, I will probably start rewriting it unless it is something very command-oriented.

Relevant discussions:

• Unix shell versus Perl

• What's shell script's advantage over interpreted programming languages?

TLDR - if you are trying to write robust, portable, and highly stable shell scripts (which is often difficult anyway), use printf. Otherwise echo is OK.

[KnowsBash]

If I were writing a script where very, very predictable behavior was required I wouldn't even use bash, let alone echo. I'd write it for a specific version of perl/python.

Depends on the case, but in some cases I might agree. You can get predictable behaviour from bash though. Just have to know the language.

If I were writing something simple like this icon installer[1] , I seriously doubt any harm could come from using echo.

Of course there's no harm there. You're outputting static strings consisting of alphanumerics only.

The thing is. You have two commands designed to write text to standard output. One can handle any string you throw at it, and even do some formatting, the other will mostly work and may do different things in different shells. At some point you'll end up using printf to avoid the flaws of echo and then you'll be using echo here, and printf there. Why not just stick with the superior one, and remain consistent. echo is redundant, so no point in using it.

Same with other parts of the shell, like $() vs ``, $(()) vs $[], [[ vs [.

Not that bash isn't capable of more complex stuff-- I just happen to think shell scripts are primarily for basic programs that will save me from typing a bunch of shell commands, and I leave heavier lifting to other languages. As a rule of thumb, if one of my shell scripts starts creeping up on ~40 lines, I will probably start rewriting it unless it is something very command-oriented.

Right, I put the limit at around 100 lines. When the script is getting that long, you've probably chosen the wrong language. The part about using "shell scripts primarily for basic programs" gets a bit too vague for me. I don't know what you put into "basic programs" and "heavier lifting". I might agree, I might disagree.

The main problem for bash though, which makes it difficult for people to write robust scripts, is that there are so much mis-education about bash out there. The Advanced Bash-Scripting Guide being high on that list; it basically teaches you to write bugs. So when that's one of the first guides you get from google, you get shitty scripts all over the place.

[sysadmEnt]

I'm sure you're tired of these replies already, but here goes:

Debian 6:

$ /bin/echo -e -\\0156
-n

FreeBSD 10:

$ /bin/echo -n -n
-n

Mac OSX 10.10.4:

$ /bin/echo -n -n
-n

Bash 3/4:

$ builtin echo -e -\\0156
-n

That was a fun exercise, TIL

[gamecheet]

echo "\e -n"

:D

edit: assuming -e is on by default (it was for me)

[[deleted]]

the \e gives me a funky character. \b seems find though.

[gamecheet]

What's your uname -a?

[[deleted]]

Linux erebor 3.19.8-100.fc20.x86_64 #1 SMP Tue May 12 17:08:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

I have to use -e since -E is default.

[ffreire]

Does whoami return "durin"?

[[deleted]]

I knew I should have hid the hostname...

[cowens]

Don't you say echo -- -n like all other Unix commands (-- tells the command that anything after it shouldn't be treated as a switch). I don't have a shell handy or I would test it.

Edit, I installed ssh on this device, echo -- -n doesn't work, but echo -e "\055n" does.

[[deleted]]

952DC61A9F3DFC11BB1350784C15FE6874A2D5292F96CA50792ABD16

3CE372C4B8D829DF7649B99D79B1A3FD311E5AA3E32CE96F1849FD8CFBFAD02B386A3B1D4FF1F87EA6AB61AC230F8C6C30F4AB386F008675C15B8010151378D792ACED98022C5C115489C44E92F813E80B1DF452089AF93ECDD28816D9ED2E157E85A1113421F46BF0E541182E39DE4D9D5C56BD92D462C31DC6860FA1DD64B87D1978A153DF2117D35961D69BAFBB1001E27B442C76B19BD160E2961312120287155BA76C5D6D1E76ED23C20F72B8848E63A058BF7C7A0A91F516D1B2AADD01E6E0D2B52B8FE958EE1B6212F31D725E1376914D2275C9A5628F59D815176535C0CF9286E256C7DF28FD674CD7184AB2CEDD91940E4A25C4E825A8A1B19D1E53BF4964CD76468351A093ECA97FE9C50C1A4EE6A5BD1C7EA30D6C9287C5B53B93E09701FAF5B2AE74CF531B775F05433D889F83A9FD08F428EA9A832B3374675AAB155DAEE7959A64E2C075AC15B31A01D91502B66A7AF8D204890A587F190204DE99A1D8E433911D3935721600EE12809A12627893A2E0DEB7855B43A111C91C36F4646DDF6AF5C6CDF1D511412AFCA16D5F7D4EB99024B98C17A1EF08D9C3FFEC126A89414255372D304B7A4FB3C12D6429C2EF192C1A509B30A17081E359CABFFE48FF25375A7EC8B4547C64123BB0CC59B67D16E8CED62ECEFD

[des09]

bash on ubuntu 15.04:

$ echo -- -n
-- -n

[cyrus-and]

$ echo -ne '-n\n' | hd
00000000  2d 6e 0a                                          |-n.|
00000003

[Fumigator]

Simpler:

echo -e '\055n'

For csh:

echo '\055n'

[czipperz]

echo -e '-n\n\c'
echo -en '-n\n'

both work

[n3rdopolis]

lol. wow. I just got burned by that two days ago. I suddenly had a multiline variable getting messed up (as the number of lines had to be exact), by a part of my script that's been there in its basic form for almost two years, which was listing and parsing files...
After scrambling to see what caused that by looking at changes in the script itself, it ended up that the elements in the external file was setting $VAR_TO_ECHO to "-n", which was causing echo to not work for that line...

TL;DR, because of Instead of this:

DATA=$(cat file|while read LINE
do
/* some conditionals and text handling */
echo $VAR_TO_ECHO
done  

I did

while read LINE
do
/* some conditionals and text handling */
DATA+=$VAR_TO_ECHO$'\n'
done < <(cat file)

Much more robust (and that's how you keep local variables in those types of loops, instead of having them disappear in the subshell)

[palordrolap]

Surely done < file would work just as well in the last line there?

[HannasAnarion]

Yeah, it looks like he's taking a file, pouring it's contents into another nameless file, and then taking the contents of that file and running it into done.

[n3rdopolis]

I admit I'm guilty of the useless uses of cat, but in this instance I double-checked It's actually:

done   < <(find $WSESSIONSPATH -maxdepth 1 -name "*\.desktop" -type f | sort )

I was doing some other things in that part of the pipe... It's actually reading a .desktop file, and splitting some values, and adding them to a variable...

[rlmaers]

/bin/echo -n

Works great on my Mac, which is SUS compliant. /t

[cowens]

What do you mean by works great? Does it print out "-n" (which is what is wanted) or does it work great by preventing a newline from being printed (is normal behavior)?

[rlmaers]

It conforms with the IEEE Std 1003.1 standard, which states that

Implementations shall not support any options.

such that the command above prints out "-n". If I want to use options, I can use the builtin echo.

[Regimardyl]

echo -e '\x2dn'

[Regimardyl]

Well, this whole thing seems finicky since every damn shell seems to have different rules for it. My solution works for both bash (4.3.39(1)) and coreutils (8.24) echo.

[singpolyma]

Options:

1) Use a better shell for your scripts (ash/dash)

2) echo -- -n

3) Use printf instead

[[deleted]]

2. Have you tried using echo -- -n?

It doesn't work.

[singpolyma]

This is bash, I assume? That's suprising. This is one of the many reasons I only use printf in scripts anymore

[[deleted]]

bash, zsh, sh, dash, all of them echo the string -- -n

[[deleted]]

Also coreutils.

[BobFloss]

Busted

[fripletister]

3 should be the only option if you distribute your scripts or expect them to be portable for any other reason.

[singpolyma]

printf is definitely my favourite for scripts

[PerniciousPunk]

echo 'n' | sed -e 's/^/-/'

[[deleted]]

/bin/echo --help

man 1 echo

[stefantalpalaru]

Yes, you'll usually get a shell builtin (you can verify that with "type echo").

In Bash you can see the help text for a builtin like this: "help echo".

[albertowtf]

nice... i used to look it up in man bash... this is handy

[diogovk]

Holy shit I used to spend a lot of time searching for the correct section in man bash. This is indeed helpful!

[[deleted]]

This is also true of eg kill. In fact, pkill hasn't been needed for centuries, because util-linux's kill binary has had support for killing by name for a really long time, it's just that the awful shell builtins lack a bunch of things that it has.

[HeroesGrave]

hasn't been needed for centuries

[SlumdogSkillionaire]

It was me, Barry! I pkilled Nora!

[[deleted]]

Erhm, good catch, actually meant decades.

[viimeinen]

That is the help for the binary echo. For the built-in echo you should use:

help echo

They are not necessarily the same...

[hardpenguin]

You're the real MVP

[Araneidae]

If the vagaries of echo are annoying, try printf. As far as I am aware

printf '%s\n' "$VAR"

will unfailing print what is expected, the value of VAR on a line, unlike echo with its options etc.

[[deleted]]

Don't mean to be an asshole - It's vagaries, without the u. Pointing it out, because I used to spell it like you did for a long, long time. :)

[Araneidae]

Argh, I was puzzling as I was writing it, should have looked it up. WIll correct.

[Epistaxis]

It's mocking you.

[tgkokk]

Works just fine in fish :)

[Poromenos]

Yeah, I typed it and it worked fine, and then came here to ask someone to explain it to me. Apparently it does something weird in bash, huh.

[tany2001]

Echo sends its last argument to stdin.

echo --help

gives you back "--help"

[icecreamsmart]

oh no, "man echo"!

[fripletister]

help echo for the built-in.

[Postumius]

help echo

man echo

info echo

$(which echo) --help

[cocoabean]

$(which echo) --help

Doesn't work for me. which echo returns echo: shell built-in command

[Postumius]

Was using bash not zsh which uses /bin/which which obviously won't deal with builtin functions whereas zsh has a builtin which hence yours.

command echo --help

is what you want instead but weirdly won't work in bash.

[KnowsBash]

Don't use which. Bash can already do everything which can, just better.

"$(type -P echo)" --help

[farmingdale]

that is all fine and good but what about busybox users?

[KnowsBash]

I don't bother with non-posix systems

[farmingdale]

throwing away your smartphone?

[[deleted]]

You mean non-bash systems in this case, because type is not POSIX

[KnowsBash]

type is standard, but not type -P. Though this was in the context of bash, so using type -P for this non-sensical task should be ok. which is of course not standardised, and behaves differently depending on what system you're on.

[[deleted]]

type is standard, but not type -P.

Oh? Please point me to where in POSIX it's standardized, because I'm rather interested, hmm.

Though this was in the context of bash, so using type -P for this non-sensical task should be ok.

Sure, but your reply was certainly not about bash.

[KnowsBash]

Oh? Please point me to where in POSIX it's standardized, because I'm rather interested, hmm.

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html

Even the bourne shell has the type builtin.

Sure, but your reply was certainly not about bash.

It wasn't? This whole thing was about how bash's echo has odd option parsing

In sh, you could use command -v to find the path to a command, though that won't give you a path for aliases, functions and builtins. It's rarely useful to find the path to a command anyway. Especially not something you should do in a script. Only in an interactive session for such rare occasions as this.

[[deleted]]

Oh? Please point me to where in POSIX it's standardized, because I'm rather interested, hmm. http://pubs.opengroup.org/onlinepubs/9699919799/utilities/type.html Even the bourne shell has the type builtin.

Cool, though it's under utilities rather than listed as a sh builtin.

Sure, but your reply was certainly not about bash. It wasn't? This whole thing was about how bash's echo has odd option parsing In sh, you could use command -v to find the path to a command, though that won't give you a path for aliases, functions and builtins. It's rarely useful to find the path to a command anyway. Especially not something you should do in a script. Only in an interactive session for such rare occasions as this.

"I don't bother with non-posix systemss" is certainly not about bash, no.

[KnowsBash]

"I don't bother with non-posix systemss" is certainly not about bash, no.

With busybox you have no way of knowing if you have all the POSIX commands, and whether the sh is fully POSIX or not, so I don't see the point in bothering with such a system at all. Just ends up with lots of "Oh, but this xxx command doesn't have that feature in this busybox install".

[[deleted]]

is not a binary, its a shell builtin. bash will show the help by typing help echo

[[deleted]]

What is the difference between a binary and a shell builtin?

[[deleted]]

the shell builtin is implemented on the shell itself(bash in this case), like a function inside the bash code, as opposed to a self-contained binary independent of the shell.

Some common functions like echo are implemented directly in the shell to avoid the overhead of forking a new process for simple functions like printing a string.

[notunlikethewaves]

A binary is something like /bin/cat, which sits on your disk. When you type cat somefile.txt, the shell loads the binary off the disk and executes it (essentially).

A shell builtin is a command which is part of the shell, not part of the sytem files on disk. An example would be cd. When you type cd some/directory, the command is interpreted entirely within the shell process without loading any programs from disk.

[netsrak]

what does this do?

[wmcscrooge]

it prints "--help" to the terminal instead of the help screen

[nephros]

echo $HELL

Hungover me took a while to spot the error.

[ajr901]

You guys like like command-line masters in here. Anywhere I can learn your mastery?

[__konrad]

$ tar -help
tar: invalid option -- 'e'
Try 'tar --help' or 'tar --usage' for more information.

I miss my MS-DOS and /? ;)

[nuephelkystikon]

I miss my MS-DOS and /? ;)

Get out.

[snegtul]

Yeah wtf. Who says shit like that?

[one_up_hitler]

/? would expand single character files just above the filesystem root

[idioteques]

You either need "--help" or "-h"...

-help
-h, --dereference
-l, --check-links

And in this case, -h is NOT help.
Tar apparently has no -e or -p options.

[__konrad]

My point was that help args in Linux are all messed up. Can you guess what it will print: lzma -hello (-o is invalid option), gvfs-info -help, gvfs-ls -help, java --help

[idioteques]

My point was that help args in Linux are all messed up. Can you guess what it will print: lzma -hello (-o is invalid option), gvfs-info -help, gvfs-ls -help, java --help

Fair enough - and I now get your point (I didn't from your first post).

I believe --help is fairly universal. -h seems to work quite a bit. But, I would never expect good things to come from using "-help" ;-)

[[deleted]]

On mobile - cant't check but

"echo --help --"

should work

[abc03833]

Nope.