setup fails if $HOME/.bashrc does not have a new line at the end of the file

[bablokb]

When adding to $HOME/.bashrc, you must insure that you add your lines on a new line. My .bashrc did not have a newline at the very last line, resulting in garbage:

. $HOME/.profileexport PICO_SDK_PATH=/data/pico/pico-sdk
export PICO_EXAMPLES_PATH=/data/pico/pico-examples
export PICO_EXTRAS_PATH=/data/pico/pico-extras
export PICO_PLAYGROUND_PATH=/data/pico/pico-playground

Which should acutally read

. $HOME/.profile
export PICO_SDK_PATH=/data/pico/pico-sdk
export PICO_EXAMPLES_PATH=/data/pico/pico-examples
export PICO_EXTRAS_PATH=/data/pico/pico-extras
export PICO_PLAYGROUND_PATH=/data/pico/pico-playground

As soon as the setup-script sources the modified .bashrc, the script bails out because of the "error" on the first line

[lurch]

How likely is it that $HOME/.bashrc or $HOME/.profile don't end with a newline? I think that'd only happen if you tried editing the files with e.g. a Windows editor (which doesn't respect the typical Unix line-ending conventions), rather than any of the text editors included with the Raspberry Pi? 😕

[bablokb]

It is very likely, I had troubles with it. It has nothing to do with Windows, I'm using Linux exclusively since 25 years. There is nothing enforcing a new line at the end of a file, and bash and it's config-files don't need it either.

BTW: the fix is very simple: just add a new-line before writing the (first) line:

echo -e "\nexport $VARNAME=$DEST" >> ~/.bashrc

Second point: my .bashrc sources other files and this also conflicts with re-sourcing .bashrc within the given script. This is unnecessary as already pointed out somewhere else, since the variables are exported anyway.

Third point: from a Linux-perspective, it would make more sense to keep the pico environment-variables in a dedicated file, e.g. ~/.pico_env. But the whole "setup" is broken anyway from a Linux-perspective. Within Linux, you would not install software in the home-directory of a user. One of the big advantages of Linux compared to Windows is the clear separation of programs and user-files, making backup (and especially restore) much easier.

[aallan]

But the whole "setup" is broken anyway from a Linux-perspective. Within Linux, you would not install software in the home-directory of a user.

We're not installing "software" (aka binaries or compiled libraries) into the user's home directory. The toolchain is installed normally, the things that are installed into the user's home directory are git checkouts of source code the user will work on — the SDK, the example code, and other such things.

[lurch]

Not that it really matters, but just out of curiosity what editor program are you using that doesn't automatically add a newline to the end of text-files?

But the whole "setup" is broken anyway from a Linux-perspective. Within Linux, you would not install software in the home-directory of a user.

pico_setup.sh isn't a typical "software installer", it was just written to automate the many separate manual steps outlined in the Getting Started guide for Raspberry Pi users.
Longer-term we do plan to create apt-installable packages for various things, but we're still in the early days of Raspberry Pi Pico so many parts are still in a state of flux...

[bablokb]

I'm using XEmacs, but that actually does not matter. Vim will also not do anything you don't tell him to do. And VSCode also doesn't automatically manipulate files. Nano does, but that's a reason why I don't use it.

Regarding the other points: I would classify the SDK as a read-only software for normal users (SDK-developers are exceptions), the examples indeed are different.

And I also honor your efforts to supply a quick setup-helper. The reason I opened this issue was just a broken installation I experienced, and the chance that other users are hit too is a reality. And the fix is simple.

[theAkito]

I am quite baffled about how much there is to talk about when a newline is missing from the end of a file.

Solution

1. Check if file ends with a newline.
2. If it does not -> append newline.

Done.
Case closed.

---

Within Linux, you would not install software in the home-directory of a user.

This is very wrong. There are e.g. user-specific programs, which obviously will be installed in your home folder, to be accessed primarily or only by yourself. There are many package managers that do that by default and people use them all the time. See e.g. cargo or nimble.

There are also Linux distributions that make use of user-specific installations of programs, like e.g. NixOS. In this case installing a package when logged in as a non-root user, results in an installation only usable by the user who installed that package. This is pretty much the behaviour you get when installing something into your own home directory on more usual Linux distributions.

Additionally, by allowing installation to your home directory, you automatically get rid of the necessity of using a root account to install harmless software, that actually does not need root permissions. If a global installation would always be enforced, you would have to ask your administrator to permit every single fart of a software to be installed.

One of the big advantages of Linux compared to Windows is the clear separation of programs and user-files, making backup (and especially restore) much easier.

This makes even less sense.

First of all, Windows is in this regard pretty much the same as Linux. Almost everything is put into Program Files and only exceptions are put into AppData, which is the case on Linux, as well, in the way described above.

Secondly, usually you put user-specific programs that you decided to put into your home directory into a common directory, like e.g. ~/.bin. So, to back up your home folder without the programs, you would only need to exclude the ~/.bin folder in the backup program.

Example:

Exclusion options

  | -e PATTERN, --exclude PATTERN | exclude paths matching PATTERN

Source

[aallan]

I am quite baffled about how much there is to talk about when a newline is missing from the end of a file.

Please see #20. This, along with most of the other issues and a number of improvements, have been rolled into a single large PR. It is therefore taking longer to fix this than would otherwise have been the case.

Within Linux, you would not install software in the home-directory of a user.

This is very wrong. There are e.g. user-specific programs, which obviously will be installed in your home folder, to be accessed primarily or only by yourself…

Historically that's just not how UNIX worked.

[theAkito]

Please see #20. This, along with most of the other issues and a number of improvements, have been rolled into a single large PR. It is therefore taking longer to fix this than would otherwise have been the case.

That's absolutely fine. I was just referring to the specific issue at hand and time was not an issue, in the first place.

Historically that's just not how UNIX worked.

That might be true, however I was referring to the de facto present state. I was not referring to how it was a very long time ago.

All that said, I think the matter is solved and the focus should be entirely put on #20. 😃