Error from fopen after conflicting files/paths

2 visualizaciones (últimos 30 días)
z8080
z8080 el 2 de Oct. de 2020
Editada: z8080 el 24 de Nov. de 2020
I have a script that, at the end, writes the generated figure to an image file:
fileName = 'figureOne';
print('-dpng', fileName );
This has been working without problems, but now the print command generates the error
Error using fopen
The file name contains characters that are not contained in the filesystem encoding.
Certain operations may not work as expected.
Error in name (line 84)
fidread = fopen(pj.FileName,'r');
Error in print (line 85)
pj = name( pj );
Error in print
Clearly there are no unacceptable characters in the file name. This other thread suggested a couple of fixes, but none of them seem to be the case. In particular, the commands
get(0, 'Language')
locale = java.util.Locale.getDefault()
language = locale.getLanguage()
return
ans =
en_GB
locale =
en_GB
language =
en
..but I doubt the problem is with the last one being just 'en' and not 'en_GB'. Rather, what has very likely caused this (though I don't know exactly how) was me having recently copied over (with overwrite) some .m files into Matlab's directory (under toolboxes etc), from another installation (2016a). A symptom of it is the warnings that I get when starting Matlab, for several functions, such as:
Warning: Function license has the same name as a MATLAB builtin. We suggest you rename the function to avoid a potential name conflict.
But fopen is not among them, and I am not sure what to change to solve my current problem. Would very much appreciate any help with this!
  2 comentarios
Stephen23
Stephen23 el 3 de Oct. de 2020
"what has very likely caused this... was me having recently copied over (with overwrite) some .m files into Matlab's directory (under toolboxes etc), from another installation..."
Doing that is the source of hidden, latent, unpredictable, almost-impossible to debug problems and bugs that will plague you forever more. There is NO way to ensure that any function or class can or does behave as documented, basically now you will never know if anything behaves as documented.
You should just reinstall.
And in future, NEVER save your own functions (copied from anywhere) in any installation folder of any application.
z8080
z8080 el 4 de Oct. de 2020
Editada: z8080 el 24 de Nov. de 2020
That's a particularly dramatic way of putting it Stephen Cobeldick, but yes, a mistake I will not repeat... :-D

Iniciar sesión para comentar.

Respuesta aceptada

z8080
z8080 el 3 de Oct. de 2020
Editada: z8080 el 5 de Oct. de 2020
Apparently there is an easy (albeit superficial - note Stephen's answer!) fix for this, which I've been advised to do: issue the command restoredefaultpath.
This has temporarily fixed the problem for me, although the command does need to be reissued after every restart of Matlab. Might be that then using savepath as WR suggests below, mitigates it.
  2 comentarios
Walter Roberson
Walter Roberson el 4 de Oct. de 2020
You could try
savepath
after restoring the path.
z8080
z8080 el 5 de Oct. de 2020
Indeed, that's helpful, thanks.

Iniciar sesión para comentar.

Más respuestas (1)

Walter Roberson
Walter Roberson el 2 de Oct. de 2020
me having recently copied over (with overwrite) some .m files into Matlab's directory (under toolboxes etc), from another installation (2016a)
You need to reinstall MATLAB.
Sorry, but it is not worth the time to pinpoint exactly which part of MATLAB you broke.

Categorías

Más información sobre Startup and Shutdown en Help Center y File Exchange.

Etiquetas

Productos


Versión

R2016b

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by