Creating Directory in Shell Causes Last Folder to have Extra "\r" - shell

I'm writing a basic shell script that creates directories and changes directories to that folder to write in it.
Right now I have the following:
mkdir -p "Home/first/second/third"
cd "Home/first/second/third"
This produces undesired results as the file structure looks as follows:
- Home
- first
- second
- third\r
I'm looking to get rid of the \r on the third\r but am unsure why it is doing so. I've tried a ton of different variations and can't seem to figure out what the issue is with adding that extra \r

Are you sure that's the exact script?
Because the mkdir -p "Home/first/second/third" should and does create a structure like.
Home
- first
- second
- third
You do need to clarify what OS and shell you are using.
Did you create the file on the host or copy it to the host from a windows machine?
-EDIT
Use
dos2unix script.sh
to get rid of those pesky \r characters that windows put in.

Credit to #Klox for figuring this out.
Files edited on a Windows computer end in \r\n, while files edited on Linux computers end in \n.
Therefore, despite the code being compiled on Linux, it still ends created files with \r\n, causing the last directory created in a mkdir to end with \r. In order to remove this \r, files must be written in the linux environment.

Related

Why is `ls -lF` listing files with the prefix "~$" not present in the directory?

I'm currently practicing basic Shell Commands in WSL, Windows Subsystem for Linux (I do not have a linux system but I want to get familiar with commands).
I start a bash session on the command prompt window and navigate to my desktop using cd . In desktop I noticed that after using ls -lF some files with the prefix ~$ appear, such as: '~$executable.x'* or '~$file.txt'
These files are not currently present under the desktop directory, but I was able to remember that they were at one point (varying from a week to months ago).
When I do the same process in powershell windows (not using linux commands) I noticed that files displayed match the desktop and no extra files are listed.
I was wondering if anyone could explain what ~$ means in this context? my intuition is telling me they are backed up files that are somehow hidden in the desktop. After googling, all I could find is that ~ reefers to the home. I also understand that $ is the default prompt symbol for the bash shell when it is waiting for me to type something, but I'm still confused on why it would show up as a prefix for the name of a file.
Hope I made my question clear.
I'm currently reading "Linux® Command Line and Shell Scripting BIBLE" by Blum and Bresnahan but I could not find an answer there, this is my last resource after many googling attempts. Any other source for more information on the topic would be helpful.
On Windows, files that start with ~ are used for hidden files. More specifically,, the prefix ~$ are often used as backups for programs, should they crash before writing updates to a file (e.g. Microsoft Word, etc.)
From Wikipedia:
The tilde symbol is used to prefix hidden temporary files that are created when a document is opened in Windows. For example, when you open a Word document called “Document1.doc,” a file called “~$cument1.doc” is created in the same directory. This file contains information about which user has the file open, to prevent multiple users from attempting to change a document at the same time.
See: Why does Word make temporary files?
Relevant superuser question: https://superuser.com/questions/405257/what-type-of-file-is-file

Can't Copy folder to specific location using terminal - Mac

I could not find a usable solution to this seemingly simple problem, despite my best efforts.
I'm using MacOS High Sierra 10.13.6
I have a folder I want to copy with the following location:
/Users/ep9k/Desktop/Key-LogEcovaluator/whereami
I want to copy it to this directory using the terminal:
/Users/ep9k/Library/Application/Support/QGIS/QGIS3/profiles/default/python/plugins
I tried the following commands in the terminal. Notice I am in the 'whereami' folder when doing this:
whereami ep9k$ cp -r /Users/ep9k/Desktop/Key-LogEcovaluator/whereami /Users/ep9k/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins
whereami ep9k$ cp -a /Users/ep9k/Desktop/Key-LogEcovaluator/whereami /Users/ep9k/Library/Application Support/QGIS/QGIS3/profiles/default/python/plugins
I'm met with the following message indicating I am not using it correctly:
However, I created a "tester" folder on my desktop and can copy to this folder with no problems, using exactly the same command (except with the pathname changed to my tester folder).
I can also copy and paste things to this directory using the GUI "finder". What am I missing?
Your destination path contains at least one whitespace character ("Application Support"), which causes the "cp" command to think it's being given three arguments instead of two. Enclose the destination path in single or double quotes and you should be all right.

Batch FTP mget command not working with wildcard?

I have written a batch script that logs into my ftp server, then navigates to a directory. I am having trouble with the mget command, I want it to download every .dat file in the directory, but it simply returns this error:
Cannot access file '/home/minecraft/multicraft/servers/server267/world/players/*.dat':No such file or directory.
200 Type set to: ANSI
Cannot find list of remote files
Here is my script (ran from cmd)
open 66.71.244.202
USER
PASSWORD
cd /world
cd players
mget *.dat
That is by design. The most recent update to the FTP specification (RFC 3659) explicitly forbids it (see section 2.2.2):
For the commands defined in this specification, all pathnames are to be treated literally. That is, for a pathname given as a parameter to a command, the file whose name is identical to the pathname given is implied. No characters from the pathname may be treated as special or "magic", thus no pattern matching (other than for exact equality) between the pathname given and the files present in the NVFS of the server-FTP is permitted.
Clients that desire some form of pattern matching functionality must obtain a listing of the relevant directory, or directories, and implement their own file name selection procedures.
When you execute your script file with ftp, you have to turn off the globbing which will allow the use of wildcards in the script. For example:
ftp -n -i -s:scriptfile.txt
should work but
ftp -n -i -g -s:scriptfile.txt
will not.
I know this is old, but it might help someone. I had the same issue with wildcards on MGET from Windows FTP, but it was not consistent in that it worked talking to some remote systems, but not to all of them.
My script was doing this:
cd /folder/folder
mget ./-400TA/folder/*_XYZ
In the folder structure I have a set of different folders that begin with hyphens, and for whatever reason the script CD's down to just above there, and uses the relative path in the MGET. I had the same issue that some of you reported, that if I connected interactively and typed the commands one by one, it worked. But in batch, it didn't.
I followed the suggestions in this and other posts, but no joy. I don't have access to the remote systems at the moment to look at them to figure out why some worked and some didn't.
However, what I did find was this. Changing my script as follows:
cd /folder/folder/-400TA/folder
mget *_XYZ
did the trick. Simple. There's some strange interaction going on somewhere possibly with folder protections or something, but it just shows that trying out different things may get you there in the end.
I would make sure glob is on, when turned off the file name in the put and get commands is taken literally and wildcards will not be looked at.
More info:
glob:Toggle filename expansion for mdelete, mget and mput. If globbing
is turned off with glob, the file name arguments are taken literally
and not expanded. Globbing for mput is done as in csh. For mdelete and
mget, each remote file name is expanded separately on the remote
machine and the lists are not merged. Expansion of a directory name is
likely to be different from expansion of the name of an ordinary file:
the exact result depends on the foreign operating system and ftp
server, and can be previewed by doing ‘mls remote-files -’ Note: mget
and mput are not meant to transfer entire directory subtrees of files.
That can be done by transferring a tar archive of the subtree (in
binary mode).
Once you are inside your ftp try to check the glob and set it on if it is off. The default behaviour is on, from the command line when connecting to ftp with the option -g you can turn off the file name globbing.
It could very well also be a firewall issue where it is not permitting or forwarding the servers inbound connection. Happened to me.

Copying directories recursively using shell script

Should be an easy question for the gurus here, though it's hard to explain it in text so hopefully this is clear. I've got two directories on a box with some flavor of unix on it. I've got a script that I want to use to move all the files and directories from one location to another.
First, an example of how the directories look:
Directory A: final/results/2012/2012-02/2012-02-25/name/files
Directory B: test/results/2012/2012-02/2012-02-24/name/files
So you see they're very similar. What I want to do is move everything from the Directory B 2012 directory, recursively, to the same level of Directory A. So you'd end up with:
someproject/results/2012/2012-02/2012-02-25/name/files
someproject/results/2012/2012-02/2012-02-24/name/files
etc.
I want this script to be future proof though, meaning I don't want the 2012 hardcoded. Also, towards the end of a month you will potentially have data from two different months and both need to be copied into the 2012 directory. So here is the command I used in the shell script file:
CONS="/someproject";
ROOT="/test";
/bin/cp -r ${ROOT}/results/* ${CONS}/results/*
but this resulted in:
/final/results/2012/2012-02/2012-02-25/name/files
and
/final/results/2012/2012/2012-02/2012-02-24/name/files
So as I hope is clear, it started a level below where I wanted it too. Can anyone fill me in on what I'm doing wrong, if they can understand what I'm even trying to explain. My apologies if it's not clear. I'm sure this is a fairly simple fix but I'm not sure what to do. Shell scripting is not a strong point of mine.
One poster suggests rsync, which is overkill.
cp -rp will work fine. if you want to move the files, just mv the directory -- it and everything under it will move too.
The only real problem here is the use of terminating *'s in the command line in the original script. You don't need the *, you're just trying to pass directories to the cp command, you aren't trying to pass it the names of all the files already in the source (and more importantly, the destination).
You could also use a tool like rsync to make sure your source and target are synchronized.
rsync -av ${ROOT}/results/ ${CONS}/results/
You specified that you want to "move" the files, though. Which means deleting the originals after they're copied:
rsync -av --remove-source-files ${ROOT}/results/ ${CONS}/results/
If you start playing around with rsync, be sure to read the man page about how it treats trailing slashes.

How can I gain permission to rename a file for my Ruby program?

As per the answer to this question, I am trying to backup a file by renaming it, before I replace it with a new, modified file with the old name.
As per the comments and the documentation here, I am using the following line of code:
File.rename(File.basename(modRaw), File.basename(modRaw)+'.bak')
However, when I do so, I get the following error at runtime:
The program then aborts. (leatherReplacer.rb is the name of my program, and line 88 is the above line of code)
How do I allow my program to rename the files it needs to to run successfully?
Windows has some special rules regarding permissions. The important one at work here, is that the OS prevents moving or renaming a file while the file is open.
Depending on the nature of your code (in size and scope) and the importance of the file you're trying to back up, it may be unfeasible or otherwise not worthwhile to refactor the code in such a way as to make backups possible.
You probably don't want to be calling File.basename in there, that strips off the directory:
Returns the last component of the filename given in *file_name*, which must be formed using forward slashes ("/") regardless of the separator used on the local file system.
So, if modRaw is /where/is/pancakes.house, then you're saying:
File.rename('pancakes.house', 'pancakes.house.bak')
But pancakes.house probably isn't in the script's current directory. Try without the File.basename calls:
File.rename(modRaw, modRaw + '.bak')
If you are owner of that file, use File.chmod to set desired permissions.
I don't know much about ruby, but could you run it under command line/bash with admin privileges, such as "run as administrator" or "su root"?
According to Objectmix and ruby-forum, you should set it to 755 or +x, then perhaps chown to yourself.
try using full file path e.t
File.rename('c:\pancakes.house', 'c:\pancakes.house.bak')
in win7 i encounter same problem

Resources