New-lines in credit text

[jkbd]

I just build on Arch Linux commit 7f14f007caca0d169705f110570795d5d101b4dd and the credit text contains unprocessed new-line characters (\n). I cloned the repo and built from scratch.

See screenshot:

[SpotlightKid]

Problem still exists in release 1.1.0. See also the master_me AUR package.

[falkTX]

Try with 62f03839e65f57620ebf097c46f6b1e8cc1b31d0 please

[SpotlightKid]

No change, issue still there:

[falkTX]

How can I reproduce this build setup? so it is possible to run arbitrary commands in it

[SpotlightKid]

I built from Git master, just using these commands:

git clone https://github.com/trummerschlunk/master_me.git
cd master_me
git submodule update --init --recursive
unset CXXFLAGS
make VERBOSE=1 SKIP_NATIVE_AUDIO_FALLBACK=true

This is on Manjaro with GCC 12.2.0 and faustpp installed via the AUR faustpp-git package.

Then I just ran the standalone version directly from checkout. I also checked the LV2 plugin version.

[falkTX]

what shell does manjaro use then? maybe related to that

[jkbd]

Interesting idea. I used FISH in a standard Gnome terminal emulator. BASH is default with Arch Linux.

[falkTX]

could you try staring a bash shell, cleaning the build and retrying? would save me the time installing arch/manjaro if that is indeed the source of the issue.

[jkbd]

Okay. I cloned a fresh repository:

> git clone https://github.com/trummerschlunk/master_me.git
> cd master_me
> git submodule update --init --recursive
> git log | head -n1
commit 1e9f7e408319273d7ee7b5191e982d9814a7ee76
> bash
$ time make
real	21m6,927s
user	10m38,201s
sys	1m31,691s

Meanwhile I started JACK in another terminal and dreamed about fast computers.

$ ./bin/master_me

No change:

[SpotlightKid]

@falkTX Are you using echo to write these strings? If so, maybe you're missing the -e option?

[jkbd]

Probably not, because the shell operates on single-quoted strings here and I assume it is not the last to process these strings.

[jkbd]

Oh! My bad! The option -e effects single quoted strings!

echo -e 'new\nline'
new
line

[falkTX]

@falkTX Are you using echo to write these strings? If so, maybe you're missing the -e option?

echo -e is a GNU thing, it does not work on macOS or BSD afaik. besides, make with echo -e doesnt work here.

[SpotlightKid]

make with echo -e doesnt work here.

Works here and the info text shows up with proper line breaks then. Maybe you need to add SHELL=/bin/bash to the Makefile.

You can also use an $(ECHO) variable for the echo command, which you set according to the shell or OS.

The problem is that GNU echo and the Bash builtin echo command do not interpret escape sequences without the -e option.

But why does BuildInfo1.hpp need to be generated anyway? It does not seem to contain anything depending on the build environment.

[falkTX]

But why does BuildInfo1.hpp need to be generated anyway? It does not seem to contain anything depending on the build environment.

that one doesn't need it anymore, but used to. only the 2nd build info needs it for now.

but issue needs fixup anyway. I just tested on a regular makefile, with this content:

aa:
        echo -e testing

then running the target I have:

$ make aa
echo -e testing
-e testing

The problem is that GNU echo and the Bash builtin echo command do not interpret escape sequences without the -e option.

that is the whole point I want though. I do NOT want the interpreted \n to appear as newlines, I want the raw \ and n. this is why the current/latest git has NEWLINE = \\\\n as variable, to purposefully deny the raw newline from being interpreted and converted. seems for you it is never converted by default and we end up with double un-escaped sequences.

we need to find a way that works cross-platform and cross-shell, all the time. (it is not only master_me that needs it btw, there is at least 1 step in DPF that makes use of the same newline-style sequence)

[SpotlightKid]

we need to find a way that works cross-platform and cross-shell, all the time.

Maybe just use template files with placeholders and sed to replace those? Of course, when the replacement values themselves contain newlines, it gets complicated again :)

[falkTX]

so, question.. if you change in https://github.com/trummerschlunk/master_me/blob/62f03839e65f57620ebf097c46f6b1e8cc1b31d0/Makefile#L180

from:

NEWLINE = '\\\\$(nothing)n'

to:

NEWLINE = '\\$(nothing)n'

does it work for you?

for sed, we again have an issue because GNU and BSD sed act differently, and the BSD variant is missing some features we are used to in Linux.. :(

[SpotlightKid]

does it work for you?

Yes.

[falkTX]

See if it works now with e37a1e08f8b2897f06878df2027f4a02c92ae395 Thanks!

[SpotlightKid]

Yes, looks good!

[falkTX]

This was meant to be closed before but forgot. v1.2.0 is coming up soon which will include the fix.