filelocation = "../"//filename
PRINT *, "Attempting to open ", TRIM(filename)
OPEN(fh1, FILE = filelocation, STATUS='old',IOSTAT = io)
Can anyone tell me please what is the meaning of "../"// in the first line?
The string
../
is Linux for the parent directory of the current working directory. This may or may not work on a Windows machine. The two characters
//
represent the Fortran operator for string concatenation. So
"../"//filename
sets filelocation to refer to a file named filename in the parent directory of the directory the program thinks it is executing in.
Related
filelocation = "../"//filename
PRINT *, "Attempting to open ", TRIM(filename)
OPEN(fh1, FILE = filelocation, STATUS='old',IOSTAT = io)
Can anyone tell me please what is the meaning of "../"// in the first line?
The string
../
is Linux for the parent directory of the current working directory. This may or may not work on a Windows machine. The two characters
//
represent the Fortran operator for string concatenation. So
"../"//filename
sets filelocation to refer to a file named filename in the parent directory of the directory the program thinks it is executing in.
When I run a commandline program (which internally deletes a log file) from CMD prompt, it's working as expected.
But the same command when run in a PowerShell prompt is not deleting the log file. The command is run successfully except for the log file deletion. There is no error or exception thrown from the PowerShell prompt.
How does PowerShell differ from a CMD prompt in the Windows environment with respect to file handling, in this case it's deleting a file?
Note: Both the CMD prompt and PowerShell are run as Administrator.
The source code of the program looks like this:
WIN32_FIND_DATA fd;
LPCWSTR search_path_wstr = ws.c_str();
HANDLE hFind = ::FindFirstFile(search_path_wstr, &fd);
wstring wsFilename(fd.cFileName);
string cFileName(wsFilename.begin(), wsFilename.end());
string absoluteFilename = strPath + "\\" + cFileName;
const char *filename = absoluteFilename.c_str();
remove(filename);
remove() is the function which deletes the file.
Update: I have tried changing remove() to DeleteFile(), the behavior is still same.
Update 2: I have found the root cause. PowerShell is returning an absolute path whereas the CMD prompt is returning a relative path. This is not part of the above code snippet.
Now I need to find whether the path is relative or not. There is a Windows function, PathIsRelative(), but it takes LPCWSTR as input and again some conversion is required.
My psychic powers tell me that the file name has non-ASCII characters in it and the error in the failing case is "file not found."
In the code, you copy wide characters into regular chars. For anything outside of ASCII, this won't do what you want.
Your code sample doesn't show how you get the source string or strPath.
It's possible that, when you enter the search string in the CMD case, it's got some non-ASCII characters that are representable in the current code page, and those values are copied to wide characters and then back without harm, and the remove works.
When you enter it in PowerShell, you probably get UTF-16 encoded text. When you copy those values back to regular chars, you're not getting the same string, so the remove probably fails with "file not found."
Don't do this:
string cFileName(wsFilename.begin(), wsFilename.end());
Work with wide strings consistently, without any conversions. If you must convert between wide and narrow strings, you must know the encoding and actually transcode the data, not just copy it.
Im running a long process using ProgressBox, and in that process im using System.Web.HttpContext.Current.Server.MapPath() method, which throws exception because System.Web.HttpContext.Current is null, Is there any method to do same functionality?
You can use
HostingEnvironment.MapPath(string path)
Yes.
Sitecore.IO.FileUtil.MapPath(string path)
Maps a virtual file path to a physical file path.
Parameters
path - A virtual file path.
Return Value
The physical file path.
Remarks
If the file path is blank, contains a backslash () or contains the string "://" the path itself is returned.
Example
The following example returns the physical filename of the mydata.xml file in the data folder. Afterwards the filename variable holds a value like "c:\inetpub\wwwroot\default website\sitecore\data\mydata.xml".
string filename = FileUtil.MapPath("/sitecore/data/mydata.xml");
At the end of a simulation, I want to write some results as an appended row to a data file. The code I am using is the following, where you can assume that outFile was correctly allocated as an std::ofstream, that output_file is a std::string containing a valid path to a file that does not yet exist, and that the variables printed out to the file are just int types that get values during the simulation.
outFile.open(output_file.c_str(), std::ios::out | std::ios::app );
outFile << num_nodes << ", " << tot_s << ", " << tot_c << ", " << tot_d << std::endl;
outFile.close();
I've checked whether it correctly opens the file with the ofstream::is_open() function and it returns false. However, I can't figure out why. I've tried it with many different file names and directory paths, all of which I have checked and they are valid (no typos, etc.)
The file being written is just into a folder on the desktop where I create files all the time, so I don't see how it could be a permissions issue. If it was a permissions issue, how can I check that?
Otherwise, what else can be preventing it from writing to the file?
Added:
Following up on the comments, after adding a call to perror(), it is displaying the "No such file or directory" error. The file path in question is:
/home/ely/Desktop/Evolutionary_Dynamics/GamesOnCycle/data/test.data
I want this file to be created, and all the directories in that path exist, it's all spelled correctly, etc., and there are no weird permission issues with the GamesOnCycle folder or its data subfolder. Note that it is a linux system (Ubuntu 11.04) so the forward slashes are correct for the file path, unless I'm missing something that C++ has to have w.r.t. file paths.
This could be happening due to several reasons.
1) The file is already open.
2) All the directories in the file path are not created.
3) Lack of file permissions.
For an additional reference, please see When will ofstream::open fail?
This may sound bad, but are you on windows or linux? If windows, for your file path, do you have it defined with double "\" in your string, or just one? If just one, you aren't putting the characters in your path that you think you are. To be safe, use the "/" character.
So if you had this:
string pathname = "C:\Users\me\Desktop";
That is NOT a valid path. You are escaping "\U", "\m" and "\D" into your string. You'd need this:
string pathname = "C:\\Users\\me\\Desktop";
or
string pathname = "C:/Users/me/Desktop";
The "/" isn't an escape character.
It's what seems likely to me.
This is a main file that I am using to test methods before I implement them. I am trying to get the list of all files in a directory, write them to a txt file (It works fine until here), then read the file names from that text file.
using namespace std;
string sysCall = "", location = "~/Documents/filenames.txt";
string temp = "";
sysCall = "ls / > "+location;
system(sysCall.c_str());
ifstream allfiles(location.c_str());
allfiles.good();
getline(allfiles, temp);
cout<<temp<<endl; //At this point, the value of temp is equal to ""
return -1;
After the program runs, no text has been outputted. From what I've read in other peoples' questions, this should work (but obviously doesn't). What am I doing wrong here?
EDIT: allfiles.good() returns false, but I don't understand why it would return that...
ifstream allfiles("~/Documents/filenames.txt"); doesn't do what you think it does. The tilde ~ character is not part of the filename -- it is a special character interpreted by some shells. You need the entire path, with no ~ or $ characters in it.
Try setting location to "/tmp/filenames.txt", or just "filenames.txt".
Also, if Boost.Filesystem is available to you, you could use a directory_iterator instead of invoking /bin/ls.
I'll bet the system() call expands the ~ in the filename to your home directory (e.g. /home/mrswmmr), but ifstream does not. Replace the ~ with the full path to your home directory and it should work.
It has no guarantee to work because system gives no guarantee.