I installed MongoDB and tried to run it on terminal. It just shows up 'mongo' is not recognized as an internal or external command, operable program or batch file.
I have set the path to bin folder inside Environment variables too. One thing I noticed is I might have a missing file inside bin folder and that is mongo. Because I have mongod and mongos file inside the bin folder. I tried to uninstall and reinstall the program and it was still not working.
I have no idea it's what that I'm missing. Please help out
Finally I have found the solution,
Mongo shell no longer ships with server binaries. We can download it from MongoDB Shell Download
Then we should extract the contents of the bin from the downloaded zip file to the bin file of the MongoDB folder and run mongosh instead of mongo on the terminal
I have started developing a website, saved in my local folders, and I am trying to save it to a GitLab repository. I created a new repository on GitLab and then did the following:
cd existing_folder
git init --initial-branch=main
git remote add origin https://gitlab.com/...
git add .
git commit -m "Initial commit"
git push -u origin main
The project comprises two folders, Server and Client, the Client is a React App. However the Client folder is appearing as a red folder icon that can't be opened:
When I click on the initial commit it says that Client has been added as a Subproject commit:
I don't know what this means, I have built websites with a similar structure before and Gitlab has not done this. I just want the contents of both Client and Server folders to be saved in the repo.
What you did:
Created a Git repository holding the client side of the app, and committed stuff to that. This repository resides in client/.git/. It contains files that are presumably named things like main.js and so on (or main.ts and so on, if TypeScript, etc.).
Created, in .git, a second, over-arching Git repository holding the server side of the app, and committed stuff to that. This repository resides in .git/ and contains files named server/functions.js and so on. Git will be calling this second over-arching repository a superproject. It's just a Git repository though, albeit one with one special property.
Note that as far as Git is concerned, folders don't even exist: files just have names with embedded slashes—always forward slashes, never backslashes—in them. Git will convert these to the folder-and-file arrangements that your OS requires, as needed. This deals with any backslash things that the OS requires as well (e.g., converting names from foo/bar.js to foo\bar.js on Windows). But for the most part this is invisible and we can pretend that we have folders full of files; we're going to work with OS-level files extracted from commits anyway, and those really are files-in-folders. So for the rest of this we'll pretend we do have folders.
Anyway, for good (security) purposes, Git refuses to ever store anything named .git. So all the files in client/.git/* literally cannot be stored: you cannot put the sub-repository in client into the superproject in ., even though ./.git holds server/ and all those files just fine.
Instead, Git will add to the superproject something that Git calls a gitlink. This is an entry that says: After you have cloned and checked out a commit for the superproject, clone another Git repository too. In that new, additional Git repository, I have saved the raw hash ID of the commit you should check out in that sub-project.
This is why you see that instruction:
Subproject commit 327f06...88c
That's the thing that makes this superproject Git repository a superproject: it contains a gitlink named client, and the gitlink itself—which is otherwise just like a file—says 327f06...88c. That 327f06...88c hash ID is the hash ID of a commit in the Git repository that Git should clone and place into a client folder within the superproject.
Now, the trick here is that for Git to run:
git clone <url> client && (cd client && git checkout 327f06...88c)
Git is going to need to know the url to use on this command-line. The gitlink records only the commit hash ID and the path name client. The URL goes into a separate file, as chickahoona mentioned, named .gitmodules.
The thing is, when you ran:
git add .
this will not have created the .gitmodules file for you. To create that file, you must use git submodule add instead of git add. The git submodule add command takes the same kind of argument as git add—the name client in this case—but also takes a URL, which it will add to the .gitmodules file in the form that Git will need to run the git clone command later.
You won't have to run this git clone command on your computer, because you already have a Git repository in client/.git. So the fact that git add . only does half the job doesn't affect your use of this superproject/gitlink pairing. But it means no one else can use your superproject because the cloning directive is missing.
What's not clear is whether you, personally, want to store your server and client in two separate Git repositories like this—one a superproject and one a submodule—or whether you want to store this in, say, three Git repositories:
one for the server only,
one for the client only, and
one to bind them.1
The last one would be the only superproject in the setup, containing only two gitlinks and a .gitmodules file referring to the two submodules. The server's files would be in a Git repository stored in server/.git and the client's files would be in a Git repository stored in client/.git (as they are now).
Or, perhaps you don't want any submodules at all. In this case, you will need to remove the client/.git folder (or move it elsewhere). This will destroy (or move elsewhere) the entire repository containing the client. You will, however, retain any working tree files from that repository. Now that the inner repository is gone, those working-tree files can be git add-ed to what was the superproject. These files will have named like client/main.js and Git will create a client/ folder and extract them to files named main.js and the like within that client/ folder.
Only you can decide what you want done here. Decide and then proceed: either add the submodule correctly, with git submodule add, or turn the server into a submodule as well and add that, or remove (or move) the client Git repository but not the current version of the client files.
1Three rings for the Elven-kings under the sky,
Seven for the Dwarf Lords in their halls of stone...
My guess would be that you were doing a git init in the wrong folder. Now your Client folder is maybe a submodule of the actual top git repo.
Check if you have in your Client folder a hidden .git directory
To fix that remove the .git folder in the Client directory. Also check for a file called .gitmodules in the top folder and remove it if it exists.
I am trying to download an artifact from a Jenkins project using a DOS batch script. The reason that this is more than trivial is that my artifact is a ZIP file which includes the Jenkins build number in its name, hence I don't know the exact file name.
My current plan of attack is to use wget pointing at: /lastSuccessfulBuild/artifact/
to do some sort of recursive/mirror download.
If I do the following:
wget -r -np -l 1 -A zip --auth-no-challenge --http-user=**** --http-password=**** http://*.*.*.*:8080/job/MyProject/lastSuccessfulBuild/artifact/
(*s are chars I've changed for posting to SO)
I never get a ZIP file. If I omit the -A zip option, I do get the index.html, so I think the authorisation is working, unless it's some sort of session caching issue?
With -A zip I get as part of the response:
Removing ...+8080/job/MyProject/lastSuccessfulBuild/artifact/index.html since it should be rejected.
So I'm not sure if maybe it's removing that file and so not following its links? But doing -A zip,html doesn't work either.
I've tried several wget options, and also curl, but I am getting nowhere.
I don't know if I have the wrong wget options or whether there is something special about Jenkins authentication.
You can add /*zip*/desired_archive_name.zip to any folder of the artifacts location.
If your ZIP file is the only artifact that the job archives, you can use:
http://*.*.*.*:8080/job/MyProject/lastSuccessfulBuild/artifact/*zip*/myfile.zip
where myfile.zip is just a name you assign to the downloadable archive, could be anything.
If you have multiple artifacts archived, you can either still get the ZIP file of all of them, and deal with individual ones on extraction. Or place the artifact that you want into a separate folder, and apply the /*zip*/ to that folder.
I have an install target in my Makefile and wish to run some commands that install shared libraries(requires root permissions) and some that install config files into $HOME/.config
Usually I'd just tell the user to run sudo make install, however that results in the config file being installed to /root/.config instead of the actual users config directory.
How do I work around this issue?
Thanks alot.
You can just change the owner and permissions of the config files, although a Makefile that installs per user configuration files, is not a good idea because it would ideally need to find out how many users exist on the system to install the files for each user.
If you use the install command, you could even do
install -v -m644 -o$(USERNAME) -g$(USERGROUP) $(FILE) $(USERHOME)/.config/$(FILE)
A better approach would be to let the program install the default config files from a system wide directory when it doesn't find them, for example
/usr/share/my-application/default-config/config.conf
and then the program would search for the files in the appropriate directoy and copy them to the $HOME directory of the user that is currently running the program, that if the files are modifiable by the user, otherwise you just access them from their system-wide location.
I am trying to run a batch file right before the installation begins,
Just after the user chooses the component he wants to install.
fortunately, I don't build it from basic, I have a ready iss file which depending on the component runs a batch file that you have created already.
In the batch file I trying to change the directory of the installer to specific one.
I tried to do so as I set INSTALLBINDIR and appfolder to my directory but it haven't work.
Do you know the variables I need to set so the installer will install where I want?
Edit:
I found out that I don't need to use a batch file.
To fixed a position to file you just need to put your Directory in the DestDir in [files]
You can't change the install directory directly from a sub script/program run from the installer.
You will need to set the WizardForm.DirEdit.Text in [Code] to the new value.
Alternatively, you can use a {code:...} constant for the DefaultDirName directive to get a suitable value to start with.