waff wiki function in ns-3 does not get parameters - waf

In ns-3 simulator documentation they provide a simple bash function to ease your life:
function waff {
CWD="$PWD"
cd $NS3DIR
./waf --cwd="$CWD" $*
cd -
}
This function is supposed to execute the ./waf program situated in the ns-3 root folder but inside the folder you are actually situated into.
So in the case of ~/project$ waff --run first waf will run the first script in the ~/project folder.
But if I try to run any simulation by adding one parameter to the script's command like ~/project$ waff --run "first --PrintHelp" it throws an error
waf: error: no such option: --PrintHelp.
It only works when I actually run the scripts from the root folder without the waff function.
How to modify the function to make it expand the $* to an argument between double commas?

Well, I feel embarrased because the solution was way easier than expected.
If anyone using DCE has the same problem, it's as easy as quoting the $*:
./waf --cwd="$CWD" $*
with:
./waf --cwd="$CWD" "$*"

This function works for me with bash (supposed you defined the environment variable $NS3DIR) :
function waff {
CWD="$PWD"
cd $NS3DIR >/dev/null
./waf --cwd="$CWD" "$#"
cd - >/dev/null
}
Proof it works is :
$ waff --run "wifi-simple-adhoc --help"
Waf: Entering directory `/home'
Waf: Leaving directory `/home'
'build' finished successfully (2.013s)
ns3.22-wifi-simple-adhoc-debug [Program Arguments] [General Arguments]
Program Arguments:
--phyMode: Wifi Phy mode [DsssRate1Mbps]
--rss: received signal strength [-80]
--packetSize: size of application packet sent [1000]
--numPackets: number of packets generated [1]
--interval: interval (seconds) between packets [1]
--verbose: turn on all WifiNetDevice log components [false]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintHelp: Print this help message.
$ waff --run wifi-simple-adhoc --command-template=" %s --help"
Waf: Entering directory `/home'
Waf: Leaving directory `/home'
'build' finished successfully (1.816s)
ns3.22-wifi-simple-adhoc-debug [Program Arguments] [General Arguments]
Program Arguments:
--phyMode: Wifi Phy mode [DsssRate1Mbps]
--rss: received signal strength [-80]
--packetSize: size of application packet sent [1000]
--numPackets: number of packets generated [1]
--interval: interval (seconds) between packets [1]
--verbose: turn on all WifiNetDevice log components [false]
General Arguments:
--PrintGlobals: Print the list of globals.
--PrintGroups: Print the list of groups.
--PrintGroup=[group]: Print all TypeIds of group.
--PrintTypeIds: Print all TypeIds.
--PrintAttributes=[typeid]: Print all attributes of typeid.
--PrintHelp: Print this help message.

Related

Vaadin: upgraded from v18 to v21: web ui does not load

I upgraded an existing (and working!) Vaadin application that was using v18.0.2 to v21.0.4. With that new version the server side application starts up as usual, it initializes OK and the first requests triggers the frontend compilation (which also seems to work OK, at least the log shows no abnormalities or errors), but the UI just hangs and fails to load (there is a thin blue progress bar at the top of the page which quickly reaches about 50% of the width, then it gets slower and slower and then starves at about 90% of the screen width).
I don't have the slightest clue in which direction I should check or analyze this. Any suggestion or hint what could be wrong here would be highly appreciated!
If I should attach any config or log details to help analyzing this let me know!
Later addendum:
I attach my vaadin_dance.cmd here:
#echo off
:package_entries
set fn=package.json
echo Step 1: Going to remove unsupported Vaadin v19+ entries from %fn%:
pause
rem let user see what we do:
#echo on
type %fn% | findstr /V /C:"#vaadin/application-theme-plugin" > %fn%_1
type %fn%_1 | findstr /V /C:"#vaadin/stats-plugin" > %fn%_2
type %fn%_2 | findstr /V /C:"#vaadin/theme-live-reload-plugin" > %fn%_3
type %fn%_3 | findstr /V /C:"#vaadin/theme-loader" > %fn%_4
rem remove an already existing backup - just in case (if there were one the cp below won't work)
rm %fn%~
rem rename back to original and keep a backup:
cp -b -f %fn%_4 %fn%
rem delete the temp. files":
rm %fn%_?
#echo off
echo unsupported Vaadin v19+ entries removed from %fn%
:local_stuff
echo Step 2: Going to remove project local stuff:
pause
rem let user see what we do:
#echo on
rmdir /S /Q .\target
rmdir /S /Q .\node_modules
rmdir /S /Q .\frontend\generated
rm package.json
rm package-lock.json
rm pnpm-lock.yaml
rm pnpmfile.js
rm tsconfig.json
rm types.d.ts
rm webpack.config.js
rm webpack.generated.js
#echo off
echo project local vaadin-generated stuff removed.
:global_stuff
echo Step 3: Going to remove global stuff: removing pnpm stuff
pause
rem let user see what we do:
#echo on
rm -r -f %USERPROFILE%\.pnpm-debug.log
rm -r -f %USERPROFILE%\.pnpm-state.json
rmdir /S /Q %USERPROFILE%\.vaadin
rmdir /S /Q %USERPROFILE%\.pnpm-store
rem just in case - I encountered them here, too:
rmdir /S /Q D:\.pnpm-store
rmdir /S /Q U:\.pnpm-store
#echo off
echo global vaadin-installed stuff removed.
rem clear (and preload) default repository:
:repo_stuff
echo Step 4: Going to empty m2repository!
pause
rem let user see what we do:
#echo on
rem strange enough I again and again got "access denied" on certain .jars ||-( So we first take ownership...
takeown /R /F %USERPROFILE%\.m2\m2repository
rem ... before removing the stuff:
rm -r -f %USERPROFILE%\.m2\m2repository\*
#echo off
echo m2repository cleaned.
echo.
pause
The process with the above .cmd file is such, that I run first step 1, then I stop it and try to rebuildv(in a different cmd window). If that does not work, I restart it from begin and run steps 1 & 2, then I stop and try to rebuild, etc. At most after steps 1, 2, 3 & 4 I was (at least so far) always able to rebuild and execute my application. That's at least when build with or reverting to v18.0.3. With v21.x I haven't been successful so far. :-(
Second addendum with the console output:
The application starts up OK (i.e. without any error message( up to the point where I see "Tomcat has been started on port: ..."
At that point I direct my browser to that port which triggers the dispatching of the DispatcherServlet. That page never loads and the browser times out, but there is NO error message or anything giving a hint re. the type or cause of the problem on the console:
...
2021-12-17 19:36:03,459 INFO [main] org.springframework.boot.web.embedded.tomcat.TomcatWebServer: Tomcat started on port(s): 8085 (http) with context path ''
2021-12-17 19:36:23,678 INFO [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Initializing Spring DispatcherServlet 'dispatcherServlet'
2021-12-17 19:36:23,682 INFO [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Initializing Servlet 'dispatcherServlet'
2021-12-17 19:36:23,689 INFO [http-nio-8085-exec-1] org.springframework.web.servlet.FrameworkServlet: Completed initialization in 2 ms
2021-12-17 19:36:26,103 WARN [http-nio-8085-exec-1] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [2,172] milliseconds.
2021-12-17 19:36:26,103 WARN [http-nio-8085-exec-3] org.apache.juli.logging.DirectJDKLog: Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [1,457] milliseconds.
2021-12-17 19:36:26,179 INFO [http-nio-8085-exec-4] com.vaadin.flow.spring.SpringInstantiator: The number of beans implementing 'I18NProvider' is 0. Cannot use Spring beans for I18N, falling back to the default behavior
<Console output stops here and browser times out>
Unfortunately there seems no way to attach screenshots here, so I can't provide the output of the WebDeveloper's Network Tab's output here...
The Browser Inspector Console displays:
Fri Dec 17 2021 19:52:01 GMT+0100 (Central European Standard Time) Atmosphere: unload event vaadinPush-min.js:1:40213
Vaadin push loaded vaadinPush-min.js:1:44231
Failed to register/update a ServiceWorker for scope ‘http://localhost:8085/’: Bad Content-Type of ‘text/html’ received for script ‘sw-runtime-resources-precache.js’. Must be a JavaScript MIME type.
Uncaught (in promise) TypeError: ServiceWorker script at http://localhost:8085/sw.js for scope http://localhost:8085/ threw an exception during script evaluation.
Path '/login' is not properly resolved due to an error. Resolution had failed on route: '(.*)' vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58:17000
Uncaught (in promise) TypeError: class heritage e is not an object or null
to http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:1
266 http://localhost:8085/VAADIN/build/vaadin-3-1a44b245d20aa3c33130.cache.js:765
r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
promise callback*imports http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
flowInit http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
async*get action/< http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
Z http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*__resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
resolveRoute http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*a http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
promise callback*resolve http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
render http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
__onNavigationEvent http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
setRoutes http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:58
r http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
<anonymous> http://localhost:8085/VAADIN/build/vaadin-bundle-aec7d8b0cb06e0cbb6bd.cache.js:1
vaadin-3-1a44b245d20aa3c33130.cache.js:1:153
​
How is a non-Vaadin intern supposed to decode that stuff and analyse what's going wrong here?
I got the issue replicated and the problem is that in development mode I got a 400 (Bad Request) in the console from Flow.ts with the faulty response Error 400 Invalid location: Location parameter missing from bootstrap request to server.
The fix was to delete the ./frontend/generated folder after which the application worked as it should when running mvn clean jetty:run. But the vaadin:clean-frontend goal should remove the generated folder in frontend which at least for me was the problem.
Check the inspector and look if there is any exceptions in the console.
I just upgraded to v22.0.1. With that new version my application now loads again! Beats me what was broken in versions 19.0.x - 21.0.4 that caused my application's UI to not load.
But there are still one issue:
The initial page is not the application's main-page but some odd self-additionalManifestEntries-page (see my append
Vaadin v22: Odd page displayed each time after login to application). I always need to reload the main page to enter my actual application.

Replacement string not working in GNU parallel

I have the script run_md.py which produces the file test.dcd from the input file named test.pdb.
I want to execute the same command on multiple input files (test*.pdb) on a remote server using GNU parallel and transfer the result back to the local computer. Therefore, I'm using the following command:
parallel --trc {.}.dcd -j 2 -S $SERVER1 './run_md.py {} 1000' ::: test*.pdb
The command is running as expected on the server using 2 slots. However, the files are not transferred back and I get the following error:
rsync: link_stat "/home/bougui/{.}.dcd" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1655) [Receiver=3.1.1]
It looks like the replacement string is not working. How can I make it works?
Below is the output of parallel --version:
GNU parallel 20130922
Copyright (C) 2007,2008,2009,2010,2011,2012,2013 Ole Tange and Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
GNU parallel comes with no warranty.
Web site: http://www.gnu.org/software/parallel
When using GNU Parallel for a publication please cite:
O. Tange (2011): GNU Parallel - The Command-Line Power Tool,
;login: The USENIX Magazine, February 2011:42-47.
What you are doing is 100% correct. So something on your system is breaking this. Please try this on another system and if possible follow REPORTING BUGS from man parallel.
The bug reported in that thread has been fixed and this feature works well with the latest version of GNU parallel (20160622). The GNU parallel version 20130922 packaged with Debian 8.5 is buggy for the usage of {.} string replacement, as described below:
With more test I found that the output file must be specified with a replacement string in the command run in parallel.
For testing purpose, you can find below a complete example that others can run:
echo This is input_file > input_file && parallel --trc {}.out -S $SERVER1 cat {} ">"{}.out ::: input_file
The example above works well. When I use the substitution string {.} as below:
echo This is input_file > input_file.in && parallel --trc {.}.out -S $SERVER1 cat {} ">"{.}.out ::: input_file
It works, as well. However, if I didn't specify {.}.out in the command run in parallel as below:
echo This is input_file > input_file.in && parallel --trc {.}.out -S $SERVER1 cat {} ">"input_file.out ::: input_file
... I reproduce the error:
rsync: link_stat "/home/bouvier/{.}.out" failed: No such file or directory (2)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1655) [Receiver=3.1.1]
rsync: [Receiver] write error: Broken pipe (32)
Therefore the output file must be specified in the command run in parallel.

GNU Parallel: suppress warning when input is read from terminal

When input is read from terminal, GNU Parallel always displays a warning:
parallel: Warning: Input is read from the terminal. Only experts do this on purpose. Press CTRL-D to exit.
But sometimes I do want to read from terminal (e.g., when I'm copy & pasting stuff from elsewhere entry by entry). Is it possible to turn off this warning? I couldn't find such an option in man parallel or man parallel_tutorial.
Note that I don't want a cheap solution like 2>/dev/null, since warning messages from other programs will be turned off, too. For instance, consider the following simple script:
#!/bin/bash
function print12 () {
echo "printing $1 to stdout"
echo "printing $1 to stderr" >/dev/stderr
}
export -f print12
SHELL=/bin/bash parallel -k print12 2>/dev/null
Messages printed to stderr will all be suppressed.
Just realized that I can do a cat or some read </dev/tty to achieve my desired effect. But let's just focus on the original question.
It cannot be turned off. But see it as a praise: Since you are doing it on purpose, you are an expert (at least in the eyes of GNU Parallel).
As it is just a warning, you are free to paste your arguments and have them run: The warning does not stop GNU Parallel from reading your input.
If you really do not like the warning:
cat | parallel ...

error while executing lua script for redis server

I was following this simple tutorial to try out a simple lua script
http://www.redisgreen.net/blog/2013/03/18/intro-to-lua-for-redis-programmers/
I created a simple hello.lua file with these lines
local msg = "Hello, world!"
return msg
And i tried running simple command
EVAL "$(cat /Users/rsingh/Downloads/hello.lua)" 0
And i am getting this error
(error) ERR Error compiling script (new function): user_script:1: unexpected symbol near '$'
I can't find what is wrong here and i haven't been able to find someone who has come across this.
Any help would be deeply appreciated.
Your problem comes from the fact you are executing this command from an interactive Redis session:
$ redis-cli
127.0.0.1:6379> EVAL "$(cat /path/to/hello.lua)" 0
(error) ERR Error compiling script (new function): user_script:1: unexpected symbol near '$'
Within such a session you cannot use common command-line tools like cat et al. (here cat is used as a convenient way to get the content of your script in-place). In other words: you send "$(cat /path/to/hello.lua)" as a plain string to Redis, which is not Lua code (of course), and Redis complains.
To execute this sample you must stay in the shell:
$ redis-cli EVAL "$(cat /path/to/hello.lua)" 0
"Hello, world!"
If you are coming from windows and trying to run a lua script you should use this format:
redis-cli --eval script.lua
Run this from the folder where your script is located and it will load a multi line file and execute it.
On the off chance that anyone's come to this from Windows instead, I found I had to do a lot of juggling to achieve the same effect. I had to do this:
echo “local msg = 'Hello, world!'; return msg” > hello.lua
for /F "delims=" %i in ('type hello.lua') do #set cmd=%i
redis-cli eval "%cmd%" 0
.. if you want it saved as a file, although you'll have to have all the content on one line. If you don’t just roll the content into a set command
set cmd=“local msg = 'Hello, world!'; return msg”
redis-cli eval "%cmd%" 0

How can I tell from a within a shell script if the shell that invoked it is an interactive shell?

I'm trying to set up a shell script that will start a screen session (or rejoin an existing one) only if it is invoked from an interactive shell. The solution I have seen is to check if $- contains the letter "i":
#!/bin/sh -e
echo "Testing interactivity..."
echo 'Current value of $- = '"$-"
if [ `echo \$- | grep -qs i` ]; then
echo interactive;
else
echo noninteractive;
fi
However, this fails, because the script is run by a new noninteractive shell, invoked as a result of the #!/bin/sh at the top. If I source the script instead of running it, it works as desired, but that's an ugly hack. I'd rather have it work when I run it.
So how can I test for interactivity within a script?
Give this a try and see if it does what you're looking for:
#!/bin/sh
if [ $_ != $0 ]
then
echo interactive;
else
echo noninteractive;
fi
The underscore ($_) expands to the absolute pathname used to invoke the script. The zero ($0) expands to the name of the script. If they're different then the script was invoked from an interactive shell. In Bash, subsequent expansion of $_ gives the expanded argument to the previous command (it might be a good idea to save the value of $_ in another variable in order to preserve it).
From man bash:
0 Expands to the name of the shell or shell script. This is set
at shell initialization. If bash is invoked with a file of com‐
mands, $0 is set to the name of that file. If bash is started
with the -c option, then $0 is set to the first argument after
the string to be executed, if one is present. Otherwise, it is
set to the file name used to invoke bash, as given by argument
zero.
_ At shell startup, set to the absolute pathname used to invoke
the shell or shell script being executed as passed in the envi‐
ronment or argument list. Subsequently, expands to the last
argument to the previous command, after expansion. Also set to
the full pathname used to invoke each command executed and
placed in the environment exported to that command. When check‐
ing mail, this parameter holds the name of the mail file cur‐
rently being checked.
$_ may not work in every POSIX compatible sh, although it probably works in must.
$PS1 will only be set if the shell is interactive. So this should work:
if [ -z "$PS1" ]; then
echo noninteractive
else
echo interactive
fi
try tty
if tty 2>&1 |grep not ; then echo "Not a tty"; else echo "a tty"; fi
man tty :
The tty utility writes the name of the terminal attached to standard
input to standard output. The name that is written is the string
returned by ttyname(3). If the standard input is not a terminal, the
message ``not a tty'' is written.
You could try using something like...
if [[ -t 0 ]]
then
echo "Interactive...say something!"
read line
echo $line
else
echo "Not Interactive"
fi
The "-t" switch in the test field checks if the file descriptor given matches a terminal (you could also do this to stop the program if the output was going to be printed to a terminal, for example). Here it checks if the standard in of the program matches a terminal.
Simple answer: don't run those commands inside ` ` or [ ].
There is no need for either of those constructs here.
Obviously I can't be sure what you expected
[ `echo \$- | grep -qs i` ]
to be testing, but I don't think it's testing what you think it's testing.
That code will do the following:
Run echo \$- | grep -qs i inside a subshell (due to the ` `).
Capture the subshell's standard output.
Replace the original ` ` expression with a string containing that output.
Pass that string as an argument to the [ command or built-in (depending on your shell).
Produce a successful return code from [ only if that string was nonempty (assuming the string didn't look like an option to [).
Some possible problems:
The -qs options to grep should cause it to produce no output, so I'd expect [ to be testing an empty string regardless of what $- looks like.
It's also possible that the backslash is escaping the dollar sign and causing a literal 'dollar minus' (rather than the contents of a variable) to be sent to grep.
On the other hand, if you removed the [ and backticks and instead said
if echo "$-" | grep -qs i ; then
then:
your current shell would expand "$-" with the value you want to test,
echo ... | would send that to grep on its standard input,
grep would return a successful return code when that input contained the letter i,
grep would print no output, due to the -qs flags, and
the if statement would use grep's return code to decide which branch to take.
Also:
no backticks would replace any commands with the output produced when they were run, and
no [ command would try to replace the return code of grep with some return code that it had tried to reconstruct by itself from the output produced by grep.
For more on how to use the if command, see this section of the excellent BashGuide.
If you want to test the value of $- without forking an external process (e.g. grep) then you can use the following technique:
if [ "${-%i*}" != "$-" ]
then
echo Interactive shell
else
echo Not an interactive shell
fi
This deletes any match for i* from the value of $- then checks to see if this made any difference.
(The ${parameter/from/to} construct (e.g. [ "${-//[!i]/}" = "i" ] is true iff interactive) can be used in Bash scripts but is not present in Dash, which is /bin/sh on Debian and Ubuntu systems.)

Resources