I need to change multiple u-boot environment variables every time I setup a new embedded device e.g. ip address, ethernet address, etc.
Typing at the terminal prompt is tedious, and, I don't know if it's my terminal, buy trying to cut and paste anything more than a few characters can result in errors. Changing them in a text editor and copying that file to a specific location in flash would be much better than the terminal.
Anyone have a good way to change multiple environment variables at once?
A script file is ideal for this situation. Its much better than copy & pasting for many commands and can handle much more complexity. You can enter all your commands into a text file and create a script image using mkimage (where myscript is the text file's name):
mkimage -T script -C none -n 'My Script' -d myscript myscript.img
Then you can simply load and execute myscript.img to perform all setup tasks for the device.
For example, to load and execute myscript.img from USB stick:
usb start && load usb 0:1 ${loadaddr} myscript.img && source ${loadaddr}
It is possible to add this load command to U-Boot's default environment so all you need to do is run the name of the command. You can even add logic to the default boot sequence to automatically perform the device setup if the USB device and script file are present. Depending on the U-Boot version, you can manipulate the default environment by either modifying the U-Boot source or by editing uEnv.txt (when supported).
Scripts are also useful for maintaining multiple setup configurations that would allow you to set the device up for one of many deployment or development configurations.
I have been able to use PuTTY to copy and paste my variables into U-Boot. You can separate the declarations by semicolons to if you want to do all of the variables at once, like this:
setenv ipaddr 192.168.1.5; setenv serverip 192.168.1.10;
Related
I have an environment file named .env337_dev. I need to run this file to set the environment before running another command. How to run this file?
Inside the file, it contains several variables like this
export AB_HOME=/et/dev/abinitio/sit1/abinitio-V2 #/gcc3p32 # for 32-bit
export PATH=${AB_HOME}/bin:${PATH}
Apart from . ./.env337_devcommand which will run and set the environment, is there any other way to run this file ?
Are you looking for the user-specific .bashrc (bash is the default shell on RHEL 6) or a system-wide /etc/profile.d/<something>.sh? For the first, you would edit $HOME/.bashrc and append a line like . .env337_dev (it's still run before any "regular" command, because .bashrc is the Bash standard personal initialization file). Second option suggests that you use an absolute path.
If this doesn't answer your question, a more specific question and/or more details would be very helpful.
You tagged this ab-initio, so you should only be setting a very few environment variables, including:
export AB_HOME=<path-to-co>operating-system>
export PATH=$AB_HOME/bin:$PATH
If you are working with Ab Initio web applications:
export AB_APPLICATION_HUB=<path-to-application-hub>
export JAVA_HOME=<path-to-jdk>
export PATH=$JAVA_HOME/bin:$PATH
and specific settings for different applications, e.g.
export AB_MHUB_HOME=<path-to-metadata-hub-installation>
Typically you put those into the file .profile in your home directory, which shells evaluate for interactive sessions.
We have some local installers and zip files that we use to build our docker images. It is easy to get this to work in a Dockerfile:
FROM mcr.microsoft.com/windows/nanoserver
COPY myinstaller.exe .
RUN myinstaller.exe; \
del myinstaller.exe
The problem here is that it produces a layer for the COPY line, which increases the size of the image. A common work-around for this is to have one RUN line, that downloads the file from the Internet, runs commands, and then deletes the installation file. The problem, as written above, is that the installers are on the local filesystem.
I found that there is a --squash command for docker:
docker build --squash -t mytestimage .
This does exactly what I want: It gives me an image without this extra installer file that is not necessary. To run this command, you need to enable experimental features though. There is also an open issue to simply remove this feature:
https://github.com/moby/moby/issues/34565
Is there some alternative way of using local installers in a Dockerfile when running on Windows, that doesn't involve setting up a server to provide the files?
We ended up setting up nginx to provide files when building. On our build server, the machine building our docker images and the server that has the installer files have a very good connection between them, so downloading huge files is not a real problem.
When it comes to --squash, it is bugged for Docker on Windows. Here is the relevant issue for it:
https://github.com/moby/moby/issues/31468
There is an issue to move --squash out of experimental, but it doesn't seem to have a lot of support:
https://github.com/moby/moby/issues/38657
The alternative that some people propose instead of --squash is multi stage build, discussion here:
https://github.com/moby/moby/issues/34565
There is an alternative to --squash, if you have local installer files, you don't want to set up a web server, and you would like your docker image to be small, and you are running Windows: Use mapped drives.
In Windows, you can share folders with other users on your network. Docker containers are like another computer that is running on your physical machine, and it can access these network drives.
First set up a new user, for example username share and password password1. Create a folder somewhere on your computer. Then right click it, click properties, and then go to the Sharing tab and click "Share". Find the user that you have just created, using the little dropdown menu and Find people ..., and share the folder with this user.
Create a folder somewhere for your test project. Create a batch file setupshare.bat that looks like this:
#echo off
for /f "tokens=2 delims=:" %%i in ('ipconfig ^| findstr "Default Gateway"') do (
set hostip=%%i
goto :end
)
:end
set hostip=%hostip: =%
net use O: \\%hostip%\vms /USER:share password1
The first part of this file is only to find the ip address that the docker container can use to access its host computer. It is not the most pretty thing I've ever put together, so let me know if there's a better way!
It uses a for-loop, as that is the way to save the output of a command to a variable in batch files. The command is ipconfig, and we pipe it to findstr and searches for Default Gateway. We need to use ^| instead of just | because it is in a for-loop. The first part of the for-loop divides each line from the command on the delimiter, which is : in this case, and we only take the second token. The for-loop only handles the first line, if there are multiple entries with a Default Gateway. This script doesn't work if there are multiple entries and the first one is not the correct one.
The line set hostip=%hostip: =% is to remove a space at the start of the string.
We then have the IP address that we want to use stored in hostip. We use this in the net use command, which will map O:\ to shared folder vms on the machine with IP hostip. We use the username share and the password password1. Note that this is a very bad way of handling passwords, as they kind of should be secret!
With a batch file like this, we can set up a Dockerfile in this way:
# escape=`
FROM mcr.microsoft.com/dotnet/core/sdk:3.0
COPY setupshare.bat .
RUN setupshare.bat && `
copy O:\file.txt file.txt
The RUN command will first call setupshare.bat that sets up the network share properly. We can then use any file that we shared, for example a huge installer, and install the things that we want. In this case I have only shared a test file file.txt to see that it works, so just change that line.
I would still advice everyone to just set up a little web server, for example nginx, and use the standard way of writing Dockerfiles, with downloading files and running it in the same RUN command. That's what people expect when they see a Dockerfile, and it should be a more robust solution.
We can also hope that the Docker people either makes a COPY command that can copy, run, and delete installers in the same layer, or that --squash is implemented properly.
I have a CI system on my Windows to build my server code.
Nowadays, I also want to autobuild my IOS project daily, but it can only build in Mac system.
So I write a shell script that can build my ios project on my Mac, and I want to remotely execute my script from Windows.
How can I write a batch file on Windows to remote access my Mac and execute my script there?
So I can make my CI system to execute that batch file everyday automatically.
Or... does anyone got other better ways to do this thing?
Thanks!
Get "plink" from the PuTTY download page. Put the command(s) to kick off your Mac shell script in a file (e.g. "maccommands.txt") on your Windows computer. Then make a batch file that contains:
plink -l macusername -m maccommands.txt your.mac.ip.address
If you don't want to be prompted for a password every time, you could make a public-private keypair with an empty passphrase using PuTTYgen. Save the private key as "pc_rsa.ppk" (or whatever you want to call it). Copy the public key out of the PuTTYgen window to the clipboard, and paste it in a text editor and save it (e.g. as "pc_rsa_pub.txt").
Then transfer the file with public key over to the Mac, and add its contents to the end of ~/.ssh/authorized_keys, e.g. with cat pc_rsa_pub.txt >> ~/.ssh/authorized_keys
Then add -i pc_rsa.ppk to the plink command above to use your private key.
(This obviously has security implications, so protect the private key file. You could also use -pw password but that has even greater security implications as the password would be plainly visible within your batch file.)
Another solution is to use openssh. The benefit is not having to use an alternative format for your keys.
You can install Git for Windows. During the installation choose the third option of being able to use the "unix" tools from the command line.
I have a small wrapper utility that loads the agent to memory in github (#selfplug)
I am developing web applications using Ruby on Rails and Sublime Text 3 on OS X 10.8.4. I recently installed the package RubyTest. The tests only work when Sublime is launched using the command
subl
in terminal. Otherwise I get the error message:
/bin/sh: rspec: command not found
I think that's meant to be the case; that's implied in RubyTest's readme file on github.
However I'd like to retain the ability to launch from the dock. Is there a way I can do this?
Unfortunately, OSX applications do not pick up on your $PATH variable set in Terminal. To change the internal PATH settings in Mountain Lion (this method hasn't been tested with previous versions, although it should work), you'll need to edit /etc/launchd.conf:
Make sure you have admin privileges.
Open Terminal or your favorite substitute and see if there's anything in the file /etc/launchd.conf:
cat /etc/launchd.conf
If you get an error like
cat: /etc/launchd.con: No such file or directory
then continue with the next step. If the cat command does display some content, copy it to the clipboard.
Create a new text file with the following content, modified to fit your needs:
setenv PATH /usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:/Users/YourUserName/bin:/path/to/gems/bin
If the cat command displayed some content in the previous step, paste it into the new file before the setenv PATH command. If it already contains a setenv PATH command, just modify it to add the directories you need, such as /path/to/gems/bin
Save the new file in your home directory (/Users/YourUserName) as launchd.conf.
Go back to Terminal and enter:
sudo mv ~/launchd.conf /etc
to use admin power to move the new file to /etc, replacing anything that was there before. Depending on your previous usage of the sudo command, you may get a short "be careful doing what you're doing" message, but either way you'll need to enter your password. /etc is not directly accessible through the Save dialog unless you're a real power user and know how to get around OSX's file system restrictions.
Reboot your computer
And you should be all set. If you're interested, launchd and launchctl use the csh/tcsh syntax, so you can't use the bash/zsh export PATH=/usr/local/bin:... format.
I often work on iOS projects alongside a development server, which is always running on the same machine that I'm using to build the app. A typical scenario is that I have a rails app running on http://localhost:3000 and I'm testing on the device. In order to test on the device, I need a resolved IP address so that my app can talk to my development server on the local network.
I know that I can use GCC_PREPROCESSOR_DEFINITIONS to set some environment variable into a preprocessor macro, and I know that I can get the build machine's IP address by running ifconfig | grep -E 'inet.[0-9]' | grep -v '127.0.0.1' | awk '{ print $2}' in a bash script.
What I want to do is define MY_SERVER_URL in GCC_PREPROCESSOR_DEFINITIONS using a value such as '#"http://${BUILD_MACHINE_IP_ADDRESS}:3000"', but what I can't figure out is how to set ${BUILD_MACHINE_IP_ADDRESS} using the ifconfig script above.
I have considered editing a configuration file using a run script build phase, but the ramifications of a change like this are irritating. For example, I wouldn't want the file included in source control because my IP address changes frequently and it would cause conflicts. But I would need it to be included in the project file so that the application can access it. This would lead to a file that's required for the project to build but isn't included in the source control, which is ugly.
I've also tried running export BUILD_MACHINE_IP_ADDRESS=`ifconfig | grep -E 'inet.[0-9]' | grep -v '127.0.0.1' | awk '{ print $2}` in a run script build phase but that doesn't yield a result.
One way of doing this is to have a run-script build phase which writes a .h file that #defines the macro and is included your sources.
I don't believe that writing a .xcconfig during build will have any effect on that build.
Exporting environment variables from run-script build phases won't work for multiple reasons. First of all, environment variables may be created from build settings but don't work the other way around. Second, even if they did, a child process can't set environment variables in its parent.
For another approach entirely, have you looked into using the .local host name of your development machine instead of a numeric IP address? Check the Sharing pane of System Preferences, which will show you the domain name for your system.