There is a ncurses6 originally installed in a user home dir, let's say "/home/test", so a test environment was built over this ncurses path, a lot of (in development) apps were compiled and is working now, depending only of the current HOME env variable.
But, because of a purpose beyond our control, we have to change the user home dir. And now it's anything different from "/home/test".
The external apps and ncurses tools still working, we need just point the libraries with LD_LIBRARY_PATH and use a more specific path like we used before for ncurses tools:
LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But now, after changing the user home dir, we need to point also the terminfo database:
TERMINFO=~/bin/ncurses-6.0/share/terminfo LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But, is there any way to make the TERMINFO database path permanent without recompiling and reinstalling the ncurses ? Is it hard code in ncurses during compilation ?
The default values are compiled-in. You can override those with environment variables (TERMINFO is standard, TERMINFO_DIRS is an extension). That's not new with ncurses6 (it predates ncurses4, twenty years ago).
The most practical "permanent" change would be to put the overrides in your shell initialization.
It's possible to modify an ELF binary (there's no checksums), but the resulting path couldn't be longer. It could be shorter, since the strings are null-terminated. Since your example adds to the path, that wouldn't work for you, anyway.
Related
On my PC I have quite a few aliases, path variables and modules like npm, scoop shims, go modules, powershell/bash functions/modules and my question is, does the pc search through all of these things the moment after I run a command? or is there some kind of registry that stores all of these values so they are quickly accessible? That would be my guess but both on my linux machine and my windows pc I have syntax highlighting on and it "knows" that a command is valid even prior to running it.
I was really curious about what process is taking place here earlier today when I installed gum (charmbracelets go TUI module) and it automatically recognized "gum -file" as a valid command when I hadn't explicitly defined it anywhere and it isn't prepended with "go" or "scoop" (assuming that I used one or the other to install the module)
I tried googling this question but I was inundated with pages of irrelevant stuff regarding basic questions about path errors and bloated articles about how to add stuff to your path.
I feel like this is a silly question but I can't get node to run a .noderc file, not even to just log to the console and not even on linux where I would expect everything to work.
My use case is that for work I have to use Windows and npm has installed modules to a particular location (%HOME%\AppData\Roaming\npm\node_modules\), whereas the default module.paths in node does not include that directory. I am fine with the location, so I don't want to fix this on the npm end of things. I have easily fixed the issue by appending this path to modules.paths, so the real solution should be for me to add that to an rc file.
I tried making a .noderc in my Windows home directory, and to my surprise it seems to not be running. I did the same on my personal laptop running a linux distro (~/.noderc) and the same thing happens. A log to console or definition of a test var does not show up in the REPL.
Is there something obvious I am missing? Usually programs have a hierarchy they run through, with default configs, a system level config file (if it exists), and a user level config file (if it exists). In the case of a program like X, they are executed in order and overwrite options, where as in something like bash, they are checked in reverse order and the first one found is executed (it is common for the first line of a user level bash config to source the system level one). How does node function?
EDIT:
In the comments below where I link to an old SO thread I noticed that there is a bit of a hack involving an alias to get the .noderc to work. So I guess a better question is, how are things like module.paths configured in node? There must be a way not involving a full rebuild.
As there has been no answer for over 10 days, I am going to just post my workaround form the comment above. It looks like there is no node config file. Any further info on that welcome. In order to solve my particular problem, I used the NODE_PATH environment variable.
I personally prefer to use use config files and not environment variables for scripting issues that need to be addressed every time. Config files are always read automatically, while using an environment variable requires you to always remember to add the variable or to permanently add the variable to your environment (which clutters the environment). I prefer to restrict environment variables to specific variations from the default. However, as I said, I can't find a config file for node.
I've had a break from programming the last two years and want to start up again. Right now I'm using a Windows computer, but my work and compiler is on my Linux computer.
My question is:
Is it possible to move my entire emacs work environment from Ubuntu to Windows 10? I did some changes in emacs back in the days that I got used to and would love to continue like that on my Windows computer.
Briefly...
The most important things to copy are your ~/.emacs.d directory and your init file (see C-hig (emacs)Init File for the different filenames this might have, or check with C-hv user-init-file).
See C-hig (emacs)Windows HOME regarding where the .emacs.d directory should live on your Windows system.
Note the comments in that Info node on the site-lisp directory as well, in case you've been using elisp libraries in there (possibly without realising), as they can form part of your Emacs configuration as well.
Any byte-compiled elisp (.elc files) should remain compatible so long as you're moving to an equal-or-newer version of Emacs (which sounds likely in this case). Natuarally things do change between releases, though, and it's possible to encounter incompatibilities when upgrading, but I wouldn't worry about that in advance -- try the latest version first, and if you run into problems that you can't solve (which shouldn't be very likely), you can always install the version of Emacs you were originally using.
I have a problem where I need to know the filesystem path of the current binary, as well as those of any loading (as opposed to loaded) binaries. Here is an example (for Windows): Say we have an executable A.exe, which dynamically binds to B.dll, which in turn binds to C.dll. How could code executing in C.dll get the file paths of C.dll, B.dll, and A.exe?
Oh, and I need to be able to do it on Linux, Mac, and Windows.
On Linux, the closest thing I've found is dl_iterate_phdr, but the who-loaded-who info is missing.
On Windows, The Dynamic-Link functions don't have quite the right functionality.
On Mac, all I can find is what's in dlfcn.h, which is rather pithy for this purpose.
Thanks.
I am trying to write a bash script to do a task, I have done pretty well so far, and have it working to an extent, but I want to set it up so it's distributable to other people, and will be opening it up as open source, so I want to start doing things the "conventional" way. Unfortunately I'm not all that sure what the conventional way is.
Ideally I want a link to an in depth online resource that discusses this and surrounding topics in depth, but I'm having difficulty finding keywords that will locate this on google.
At the start of my script I set a bunch of global variables that store the names of the dirs that it will be accessing, this means that I can modify the dir's quickly, but this is programming shortcuts, not user shortcuts, I can't tell the users that they have to fiddle with this stuff. Also, I need for individual users' settings not to get wiped out on every upgrade.
Questions:
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate? tweek the reference in the source of the dev version?
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be? the user will need to access some of this data, but it's mostly for internal use. I personally work in cygwin, and I like to keep this data on separate drive, so the path is wierd, I suspect many users could find this. for a default however I'm thinking ~/gpsdata/ -- would this be normal, or should I hard code a system that ask the user at first run where to put it, and stores this in the settings folder? whatever happens I'm going ot have to store the directory reference in a file in the settings folder.
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?? though there will always be an option to add a file or folder to the command line to use that as well (it processed files all locations listed, including the "inbox")
Where should the script its self go? it's already smart enough that it can create all of it's ancillary/settings files (once I figure out the "correct" directory) if run with "./foo --setup" I could shove it in /usr/bin/ or /bin or ~/.foo/bin (and add that to the path) what's normal?
I need to store login details for a web service that it will connect to (using curl -u if it matters) plan on including a setting whereby it asks for a username and password every execution, but it currently stores it plane text in a file in ~/.foo/ -- I know, this is not good. The webservice (osm.org) does support oauth, but I have no idea how to get curl to use it -- getting curl to speak to the service in the first place was a hack. Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Sorry for the list of questions, I believe they are closely related enough for a single post. This is all stuff that stabbing at, but would like clarification/confirmation over.
Name of settings folder: ~/.foo/ -- this is well and good, but how do I keep my working copy and my development copy separate?
Have a default of ~/.foo, and an option (for example --config-directory) that you can use to override the default while developing.
If my program needs to maintain and update library of data (gps tracklog data in this case) where should this directory be?
If your script is running under a normal user account, this will have to be somewhere in the user's home directory; elsewhere, you'll have no write permissions. Perhaps ~/.foo/tracklog or something? Again, add a command line option, and also an option in the configuration file, to override this.
I'm not a fan of your ~/gpsdata default; I don't want my home directory cluttered with all sorts of directories that programs created without my consent. You see this happen on Windows a lot, and it's really annoying. (Saved games in My Documents? Get out of here!)
The program needs a data "inbox" that is a folder that the user can dump files, then run the script to process these files. I was thinking ~/gpsdata/in/ ?
As stated above, I'd prefer ~/.foo/inbox. Also with command-line option and configuration file option to change this.
But do you really need an inbox? If the user needs to run the script manually over some files, it might be better just to accept those file names on the command line. They could just be processed wherever, without having to move them to a "magic" location.
Where should the script its self go?
This is usually up to the packaging system of the particular OS you're running on. When installing from source, /usr/local/bin is a sensible default that won't interfere with package managers.
Is there a simple way to do a really basic encryption on a file like this to deter idiots armed with notepad?
Yes, there is. But it's better not to, because it creates a false sense of security. Without a master password or something, secure storage is not possible! Pidgin, for example, explicitly stores passwords in plain text, so that users won't make any false assumptions about their passwords being stored "securely". So it's best just to store them in plain text, complain if the file is world-readable, and add a clear note to the manual to warn the user what's going on.
Bottom line: don't try to reinvent the wheel. There have been thousands of scripts and programs that faced the same issues; most of them ended up adopting the same conventions, and for good reasons. Look at what they do, and mimic them instead of reinventing the wheel.
You can start with the Filesystem Hierarchy Standard. I'm not sure how well followed it is, but it does provide some guidance. In general, I try to use the following:
$HOME/.foo/ is used for user-specific settings - it is hidden
$PREFIX/etc/foo/ is for system-wide configuration
$PREFIX/foo/bin/ is for system-wide binaries
sym-links from $PREFIX/foo/bin are added to $PREFIX/bin/ for ease of use
$PREFIX/foo/var/ is where variable data would live - this is where your input spools and log files would live
$PREFIX should default to /opt/foo even though almost everyone seems to plop stuff in /usr/local by default (thanks GNU!). If someone wants to install the package in their home directory, then substitute $HOME for $PREFIX. At least that is my take on how this should all work.