Unable to source a simple bash script - linux

I understand similar questions to this been asked in SO multiple times. However, I couldn't find any usual suspects here.
#!/bin/bash
myvar="test"
if [ "$myvar" == "test" ]
then
echo "Test mode"
fi
Spent quite some time on it. Can anyone advice what am I missing?
I am able to execute the script, but couldn't source the same.
error while source bash: test.sh: line 7: syntax error: unexpected end of file
$ which bash
/bin/bash
$ bash --version
3.2.57(1)
I am able to get the same working on my another Mac. So, it's pretty much something wrong on my Mac, but couldn't figure out what it is. Also, not only the above-mentioned script, any script with "if" condition I couldn't source. Tried different examples mentioned here, same syntax error.
edit1:
$ file test.sh
test.sh: Bourne-Again shell script text executable, ASCII text
edit2:
$ hexdump -C test.sh
00000000 23 21 2f 62 69 6e 2f 62 61 73 68 0a 6d 79 76 61 |#!/bin/bash.myva|
00000010 72 3d 22 74 65 73 74 22 0a 69 66 20 5b 20 22 24 |r="test".if [ "$|
00000020 6d 79 76 61 72 22 20 3d 3d 20 22 74 65 73 74 22 |myvar" == "test"|
00000030 20 5d 0a 74 68 65 6e 0a 65 63 68 6f 20 22 54 65 | ].then.echo "Te|
00000040 73 74 20 6d 6f 64 65 22 0a 66 69 0a |st mode".fi.|
0000004c

Check for newline character differences or encoding pages.
if it something as simple as this and there is a mac involved, always check that first

As other users already stated, you can check if newline is LF because CRLF will fail in linux. if you convert the script it should be fixed. you can install a tool which can convert CRLF into LF:
dos2unix test.sh
Regarding the sourcing, not sure if this may help you with your issue. assuming the wrapper script which sources test.sh is not called from bash...
#!/bin/sh
. ./test.sh
...the if statement will fail, because bourne shell does not support '==' but if you change it to...
#!/bin/bash
myvar="test"
if [ "$myvar" = "test" ]
...the script will sourced without errors. Please note it depends on how the script is sourced, the shebang might be ignored

Okay. After 10 months, my wife helped me debug this problem.
I had an alias in .bash_profile alias fi='firebase init'
Alias name fi makes bash to confuse with if statement.

Okay finally, found the issue.
I removed my .bashrc file and its working fine. Looks like something in .bashrc was messing it.
$ source test.sh
Test mode
Thanks, everyone appreciate it.

Related

How to use bluetoothctl to report repeated proximity beacons in real time using MQTT

This is a great solution as far as it goes:
How to use bluetoothctl like hcitool lescan to report repeated proximity beacons
I want to take it one step further though: instead of printing the beacon detections to the terminal, I want to pipe each detected beacon's MAC address to a command that publishes it to a Mosquitto broker. This would be useful for adding the beacons to HomeAssistant, for example, for presence detection of a key fob attached to a person's house keys. I managed to get this idea to work by modifying the last two lines of the script above but it only publishes the first detection ... then no more. I guess somehow the scan is being turned off or aborted by trying to run the mosquitto_pub command. (something to do with interrupting the thread or subshells????)
Here are the last lines of the script with the MAC addresses of my TWO TEST BEACONS obfuscated.
You can see the full script that I modified at the link above.
) | sed --unbuffered --quiet --expression 's/^.*Device //p' \
| grep --line-buffered -E 'FF:FF::::|FF:GG::::' \
| stdbuf -oL cut -c 1-17 \
| { read topic; mosquitto_pub -d -u username -P password -m ON -t monitor/$topic; }
Note:
| stdbuf -oL cut -c 1-17 \ trims the output down to just the MAC address - e.g. FF:GG::::
The last line publishes the ON command to an unique state topic ending in the beacon's MAC address e.g. 'monitor/FF:GG::::'.
If I remove that last line the detections are added as they occur to the terminal console in an ever growing list as time goes by. But once I add the last line it only works once, then goes dead.
How can the script be made to respond to each detection, not just the first one?
And why exactly does it only respond to the first detection then hang?
The command line tools of BlueZ are not designed for this purpose, so it makes them very difficult to pipe scan results reliably. In my experience, processes die or hang, and you end up with broken pipes.
The C APIs of BlueZ are much more stable. I wrote a simple command line program in C that you could use instead of bluetoothctl for this purpose:
https://gist.github.com/davidgyoung/0a18028b4338ff6cb201fba274502662
That program must be compiled with cc scanner.c -lbluetooth -o scanner, after which you can start the scanner with just scanner. The output of the program will be something like this:
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
71:5C:23:9D:BC:7F -68 02 01 1A 02 0A 0C 0B FF 4C 00 10 06 03 1A 3B D4 B2 EB
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
4A:53:7F:64:71:EC -91 03 03 9F FE 17 16 9F FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
69:0D:FF:7B:75:65 -73 02 01 1A 02 0A 0C 0A FF 4C 00 10 05 03 1C 27 BB 63
61:39:71:E9:1D:C9 -93 02 01 1A 02 0A 18 0A FF 4C 00 10 05 01 18 3B 24 12
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
Each line above shows the MAC address of the detected bluetooth device, followed by the signal strength RSSI, then the hex bytes of the advertisement.
I use this program to pipe into other shell scripts, and have found it to be reliable over many days. Feel free to use it if helpful.

Very simple gitlab-ci.yml reports syntax error

I wrote a very simple .gitlab-ci.yml as below:
image: horchen/vscode-ext-dev
job1:
script:
- echo "Hello World"
Just echo Hello World, I think it should be able to run on any platform. But gitlab-ci always tells me there is an syntax error in it.
Running with gitlab-runner 13.2.2 (a998cacd)
on nodejs-ci aPuhC2uZ
Preparing the "docker" executor
Using Docker executor with image horchen/vscode-ext-dev ...
Using locally found image version due to if-not-present pull policy
Using docker image sha256:17af24ad877daa656e102508585c7262585be04b05a75cc89833afcfe7403ebb for horchen/vscode-ext-dev ...
Preparing environment
Running on runner-apuhc2uz-project-1-concurrent-0 via cf9f41a14878...
Getting source from Git repository
Fetching changes with git depth set to 50...
Reinitialized existing Git repository in /builds/horchen/vscode-rlcv/.git/
Checking out 93d3b0e1 as master...
Skipping Git submodules setup
Executing "step_script" stage of the job script
[: line 1: syntax error: unexpected end of file (expecting "then")
ERROR: Job failed: exit code 2
Does anyone know why it reports such an error?
--------------- Append Data -------------------
Actually I really developed on windows but I have checked the CR/LF style, also checked hexdump. And have tried to edit it on webIDE and linux VIM, both didn't find ^M in it.
Offset: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000: 69 6D 61 67 65 3A 20 68 6F 72 63 68 65 6E 2F 76 image:.horchen/v
00000010: 73 63 6F 64 65 2D 65 78 74 2D 64 65 76 0A 0A 61 scode-ext-dev..a
00000020: 66 74 65 72 5F 73 63 72 69 70 74 3A 0A 20 20 2D fter_script:...-
00000030: 20 22 72 6D 20 2A 2E 76 73 69 78 22 0A 0A 6A 6F ."rm.*.vsix"..jo
00000040: 62 31 3A 0A 20 20 73 63 72 69 70 74 3A 0A 20 20 b1:...script:...
00000050: 20 20 2D 20 65 63 68 6F 20 22 48 65 6C 6C 6F 20 ..-.echo."Hello.
00000060: 57 6F 72 6C 64 22 0A World".
The step_script stage of the job includes the before_script and script sections. Your executor is trying to execute your script section, which is causing the error.
End of line error
The unexpected end of file (expecting "then") error is often seen with Windows vs. Linux file formats. See Syntax error: end of file unexpected (expecting "then"). Try converting your gitlab-ci.yml file to have Linux line endings and see if that fixes it. There are a number of tools that can do this (see link above), including Notepad++.
If this is your issue, you may have a bigger problem: are you developing in Windows and running code in Linux? If so, you may need to setup your .gitattirbutes file to automatically convert Windows EOL characters to Linux and vice versa. See How to change line-ending settings.
Add second job without echo
If that doesn't work, then try adding another job to your pipeline that doesn't print anything. Just add something like x=2 to the script section. This might eliminate the echo in the script as a source of error.
Assign jobs to a stage
Just to be safe, create a stages section and assign both jobs to the same stage, like this:
stages:
- test
job2:
stage: test
script:
- x = 2
Troubleshoot Dockerfile
If that still doesn't help, then I would start suspecting your Docker image: horchen/vscode-ext-dev. It's possible that GitLab is trying to execute the script from the job in the container, which may be executing some code first. You may need to post your Dockerfile to troubleshoot that.
I would also suspect the EOL CRLF/LF characters of any scripts called by the Dockerfile.

Getting the hexdump of a given function

I want to get the hexdump of a given function. Until now objdump -d a.out --start-address=0x400630 and --stop-address=0x400679 is the best solution what I have found, however I do not know how to extract only the opcodes from the output.
For example from this:
4003f0: 48 83 ec 08 sub $0x8,%rsp
4003f4: e8 73 00 00 00 callq 40046c
...
I need only this:
48 83 ec 08
e8 73 00 00 00
You could use gdb on your program and x/i will print out a range of machine instructions.
May also try to pipe in cut:
objdump -d a.out --start-address=0x400630 and --stop-address=0x400679 | cut -b 14-30
you probably need to adapt your cut range for your output.

How to check which symbols on my shared library have non-position independent code (PIC)?

I'm trying to build a .deb package with debuild -i -us -uc -b and in the end I see:
Now running lintian...
warning: the authors of lintian do not recommend running it with root privileges!
W: libluajit-5.1-2: hardening-no-relro usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
E: libluajit-5.1-2: shlib-with-non-pic-code usr/lib/powerpc64le-linux-gnu/libluajit-5.1.so.2.1.0
W: luajit: hardening-no-relro usr/bin/luajit-2.1.0-alpha
W: luajit: binary-without-manpage usr/bin/luajit-2.1.0-alpha
Finished running lintian.
I have a hunch that I failed to define a "PIC code setup", which must be at the beginning of each external function:
The following code might appear in a PIC code setup sequence to compute
the distance from a function entry point to the TOC base:
addis 2,12,.TOC.-func#ha
addi 2,2,.TOC.-func#l
as specified by the ABI, page 99.
However I couldn't find the symbols which were non-PIC. Or maybe some relevant file that was not compiled with -fPIC?
Info:
system architecture: ppc64le
compiling .so library with: gcc -shared -fPIC
To find which symbols made your elf non-PIC/PIE (Position Independent Code/Executable), use scanelf from pax-utils package (on ubuntu, install it with sudo apt-get install pax-utils):
$ scanelf -qT /usr/local/lib/libluajit-5.1.so.2.1.0 | head -n 3
libluajit-5.1.so.2.1.0: buf_grow [0x7694] in (optimized out: previous lj_BC_MODVN) [0x7600]
libluajit-5.1.so.2.1.0: buf_grow [0x769C] in (optimized out: previous lj_BC_MODVN) [0x7600]
libluajit-5.1.so.2.1.0: buf_grow [0x76A0] in (optimized out: previous lj_BC_MODVN) [0x7600]
$ objdump -Sa /usr/local/lib/libluajit-5.1.so.2.1.0 | grep -A5 \ 7694:
7694: 00 00 80 39 li r12,0
7698: c6 07 8c 79 rldicr r12,r12,32,31
769c: 00 00 8c 65 oris r12,r12,0
76a0: 00 00 8c 61 ori r12,r12,0
76a4: a6 03 89 7d mtctr r12
76a8: 21 04 80 4e bctrl
On my case an absolute address was meant to be load on r12, but that's not possible for a dynamic library, so the linker used 0 for that parameter (I had to use #GOT operator, but that's the particular solution to my case).
On the luajit program, it's possible to define the address on linking time and it looks like this:
1003d0d4: 00 00 80 39 li r12,0
1003d0d8: c6 07 8c 79 rldicr r12,r12,32,31
1003d0dc: 07 10 8c 65 oris r12,r12,4103
1003d0e0: 30 ca 8c 61 ori r12,r12,51760
1003d0e4: a6 03 89 7d mtctr r12
Quite different right?
a much detailed explanation can be found on this wonderful Gentoo wiki page.
The failing lintian check is this:
# Now that we're sure this is really a shared library, report on
# non-PIC problems.
if ($objdump->{$cur_file}->{TEXTREL}) {
tag 'shlib-with-non-pic-code', $cur_file;
}
So you can probably find the offending file by looking for a .o that contains a TEXTREL dynamic section (which is making its way into your final link).
To do this, you can use readelf --dyanamic, in something like the following:
find . -name '*.o' |
while read obj
do
if readelf --dynamic "$obj" | grep -q TEXTREL
then
echo "$obj contains a TEXTREL section"
fi
done

vc80.pdb - How do I make it go away and never bother me again?

When building static libraries with VS2005 I keep getting linker warnings that VC80.pdb cant be found with my library.lib. Apparently, as a result, the edit and continue feature of the IDE fails to work any project that incorporates library.lib
What magic is needed to tell VS2005 to produce a static lib with edit and continue debug info that does NOT reference or require vs80.pdb when linked into a project?
--Upon Further Understanding--
So, In order to get edit-and-continue to function with a pre-compiled static lib, we need to place the vs80.pdb and vs80.pdb file into SVN along with the .lib, AND rename the pdb/idb to prevent conflicts when doing this with multiple pre-compiled libs.
vc80.pdb is the file that contains the debug information for your lib. In the ide Property pages:configuration properties:c\c++:output files allows you to rename this to something more appropriate, such as the name of your lib. When the linker links your lib into the target exe it looks for this pdb (there is a pointer to it in the lib) and extracts the info from that pdb and drops it in the exe's pdb.
/Fd[name] is the option for renaming the pdb
/ZI is the option for compiling with a pdb that includes Edit and Continue information.
All linked libs and the final taget exe or dll need /ZI, to enable edit and continue.
I made a tiny testlib.lib and used "dumpbin /all" to get the following showing the pointer to the debug info (this is a tiny excerpt):
SECTION HEADER #7
.debug$T name
0 physical address
0 virtual address
48 size of raw data
838 file pointer to raw data (00000838 to 0000087F)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42100040 flags
Initialized Data
Discardable
1 byte align
Read Only
RAW DATA #7
00000000: 04 00 00 00 42 00 15 15 D5 EA 1E C9 7C 10 3A 40 ....B...Õê.É|.:#
00000010: 93 63 CE 95 77 15 49 4A 03 00 00 00 64 3A 5C 64 .cÎ.w.IJ....d:\d
00000020: 65 76 5C 74 65 73 74 5C 74 65 73 74 6C 69 62 5C ev\test\testlib\
00000030: 74 65 73 74 6C 69 62 5C 64 65 62 75 67 5C 76 63 testlib\debug\vc
00000040: 38 30 2E 70 64 62 00 F1 80.pdb.ñ
If you can live without 'edit and continue', try using /Z7.
I use it for all the .lib files that are stored in source control. No .pdb file is created - the debug info is stored inside the .lib file.

Resources