summaryrefslogtreecommitdiff
path: root/libraries/base/System/Environment.hs
Commit message (Collapse)AuthorAgeFilesLines
* Implement improved "get executable path" queryFraser Tweedale2021-07-061-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | System.Environment.getExecutablePath has some problems: - Some system-specific implementations throw an exception in some scenarios, e.g. when the executable file has been deleted - The Linux implementation succeeds but returns an invalid FilePath when the file has been deleted. - The fallback implementation returns argv[0] which is not necessarily an absolute path, and is subject to manipulation. - The documentation does not explain any of this. Breaking the getExecutablePath API or changing its behaviour is not an appealing direction. So we will provide a new API. There are two facets to the problem of querying the executable path: 1. Does the platform provide a reliable way to do it? This is statically known. 2. If so, is there a valid answer, and what is it? This may vary, even over the runtime of a single process. Accordingly, the type of the new mechanism is: Maybe (IO (Maybe FilePath)) This commit implements this mechanism, defining the query action for FreeBSD, Linux, macOS and Windows. Fixes: #10957 Fixes: #12377
* Various documentation improvementsSergey Vinokurov2018-02-141-2/+2
| | | | | | | | | | | | | | | * Fix missing code example in changelog for 8.4.1 * List 'setEnv' as opposite of 'getEnv' It seems best to direct users to use 'System.Environment.setEnv' rather than 'System.Posix.Env.putEnv'. This is due to 'setEnv' being located in the same module as 'getEnv' and my virtue of working on Windows platform, whereas 'putEnv' does not have that quality because it's part of the 'unix' package. * Reflect in docs the fact that 'readMVar' is not a composition of 'takeMVVar' and 'putMVar' any more
* Allow Windows to set blank environment variablesHabib Alamin2017-07-311-5/+5
| | | | | | | | | | | | | | Test Plan: ./validate on harbormaster Reviewers: austin, hvr, bgamari, erikd, Phyx Reviewed By: Phyx Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #12494 Differential Revision: https://phabricator.haskell.org/D3726
* Initialize hs_init with UTF8 encoded arguments on Windows.Andreas Klebinger2017-07-271-86/+6
| | | | | | | | | | | | | | | | | | | | | | | Summary: Get utf8 encoded arguments before we call hs_init and use them instead of ignoring hs_init arguments. This reduces differing behaviour of the RTS between windows and linux and simplifies the code involved. A few testcases were changed to expect the same result on windows as on linux after the changes. This fixes #13940. Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar, Phyx Subscribers: Phyx, rwbarton, thomie GHC Trac Issues: #13940 Differential Revision: https://phabricator.haskell.org/D3739
* Prefer #if defined to #ifdefBen Gamari2017-04-281-14/+14
| | | | Our new CPP linter enforces this.
* base: Add handling of -- to getArgs for WindowsAndreas Klebinger2017-02-231-1/+15
| | | | | | | | | | | | | getArgs didn't match the treatmeant of -- in the RTS leading to inconsistencies between behavior on Windows and other platforms. See #13287. Reviewers: austin, hvr, bgamari, erikd, simonmar, rwbarton Reviewed By: bgamari, rwbarton Subscribers: rwbarton, thomie Differential Revision: https://phabricator.haskell.org/D3147
* Fix memory leak from #12664Bartosz Nitka2016-10-071-18/+12
| | | | | | | | | | | | | | | | | | | | | This fixes the leak with `setProgArgv`. The problem was that `setProgArgv` would not free the objects pointed to by `prog_argc`, `prog_argv` when the globals were changed resulting in a leak. The only strictly necessary change is in `rts/RtsFlags.c`, but the code in `System.Environment` was a bit confusing and not exception safe, so I refactored it. Test Plan: ./validate Reviewers: simonmar, ezyang, austin, hvr, bgamari, erikd Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D2576 GHC Trac Issues: #12664
* Typofix in System.Environment docs.Edward Z. Yang2016-08-161-1/+1
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* An assortment of typosGabor Greif2015-12-081-1/+1
|
* Convert `/Since: .../` to new `@since ...` syntaxHerbert Valerio Riedel2014-12-161-3/+3
| | | | | | Starting with Haddock 2.16 there's a new built-in support for since-annotations Note: This exposes a bug in the `@since` implementation (see e.g. `Data.Bits`)
* Update Foreign.* for Safe Haskell now that they're safe by defaultDavid Terei2014-11-211-1/+1
|
* Remove redundant explicit `Prelude` importsHerbert Valerio Riedel2014-10-191-2/+0
| | | | Since they're implied by the lack of `NoImplicitPrelude`
* Drop redundant `{-# LANGUAGE #-}` pragmasHerbert Valerio Riedel2013-09-281-1/+1
| | | | | | | | | | | | | This removes language pragmas from Haskell modules which are implicitly active with `default-language: Haskell2010`. Specifically, the following language extension pragmas are removed by this commit: - PatternGuards - ForeignFunctionInterface - EmptyDataDecls - NoBangPatterns Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Add Haddock `/Since: 4.6.0.0/` comments to symbolsHerbert Valerio Riedel2013-09-211-0/+2
| | | | | | | | | | This commit retroactively adds `/Since: 4.6.0.0/` annotations to symbols newly added/exposed in `base-4.6.0.0` (as shipped with GHC 7.6.1). See also 6368362f which adds the respective annotation for symbols newly added in `base-4.7.0.0` (that goes together with GHC 7.8.1). Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Add Haddock `/Since: 4.7.0.0/` comments to new symbolsHerbert Valerio Riedel2013-09-211-0/+4
| | | | | | | | | | | | | | | | | | These annotations were added in such a way, that the line {{{ /Since: 4.7.0.0/ }}} represents the last paragraph of the Haddock comment. Maybe Haddock will have support for this meta-syntax at some point, and be able to inherited the since-version property to the children of an annotated symbol and display the since-version property in the rendered documentation only in cases when it's not visually obvious (for instance, when re-exporting documentation strings). Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Constant-fold `__GLASGOW_HASKELL__` CPP conditionalsHerbert Valerio Riedel2013-09-171-7/+0
| | | | | | | | | | Now that HUGS and NHC specific code has been removed, this commit "folds" the now redundant `#if((n)def)`s containing `__GLASGOW_HASKELL__`. This renders `base` officially GHC only. This commit also removes redundant `{-# LANGUAGE CPP #-}`. Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Remove Hugs98 specific codeHerbert Valerio Riedel2013-09-171-4/+0
| | | | | | | For rationale. see http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/2349 Signed-off-by: Herbert Valerio Riedel <hvr@gnu.org>
* Add setEnv/unsetEnv to System.Environment; fixes #7427Ian Lynagh2013-06-151-2/+94
| | | | Patch from Simon Hengel.
* Remove nhc98-specific files and contentIan Lynagh2013-02-151-10/+0
|
* GHC.Windows: more error support (guards, system error strings)Joey Adams2012-11-171-1/+1
| | | | | | | | | | | | | | | This changes the output of throwGetLastError to include the system error message, rather than the message of our fictitious errno. It also adds several definitions to GHC.Windows, mostly from the Win32 package. The exceptions are: * getErrorMessage: returns a String, unlike in System.Win32.Types, where it returns an LPWSTR. * errCodeToIOError: new * c_maperrno_func: new
* Remove commented types in module export listsIan Lynagh2012-10-271-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These comments are rather less useful now that haddock can give docs with the same informatino in the module synopsis. Having to maintain them when making changes to the library is a pain, and when people forget about doing so there is nothing that checks that the comments are right, so mistakes tend to linger. Of the comments that my script detected, 78 of 684 were already incorrect in one way or another, e.g. missing context: Text.Show.showsPrec Comment type: Int -> a -> ShowS Actual type: Show a => Int -> a -> ShowS wrong context: Numeric.readInt Comment type: Integral a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a Actual type: Num a => a -> (Char -> Bool) -> (Char -> Int) -> ReadS a not following a class change (e.g. Num losing its Eq superclass): Text.Read.Lex.readOctP Comment type: Num a => ReadP a Actual type: (Eq a, Num a) => ReadP a not following the Exceptions change: GHC.Conc.childHandler Comment type: Exception -> IO () Actual type: SomeException -> IO () or just always been wrong: GHC.Stable.deRefStablePtr Comment type: StablePtr a -> a Actual type: StablePtr a -> IO a
* Add System.Environment.getExecutablePath (#7029)Paolo Capriotti2012-06-271-4/+7
| | | | Patch by Johan Tibell <johan.tibell@gmail.com>
* Don't use stdcall on Win64: It isn't supported; ccall is used insteadIan Lynagh2012-05-161-4/+14
|
* Fix an off-by-one error in freeProgArgvIan Lynagh2012-05-021-1/+2
|
* Add System.Environment.lookupEnv (#5930)Paolo Capriotti2012-04-101-15/+32
| | | | Based on a patch by Evan Laforge <qdunkan@gmail.com>
* Whitespace only: convert mixed tabs and spaces to spaces.Evan Laforge2012-04-091-21/+21
| | | | Signed-off-by: Paolo Capriotti <p.capriotti@gmail.com>
* System.Environment: improve 'getEnv' doc to mention closest 'setEnv' we have ↵gwern2012-02-131-6/+6
| | | | ('System.Posix.putEnv')
* Make the fileSystemEncoding/localeEncoding/foreignEncoding mutableMax Bolingbroke2011-11-181-6/+10
|
* Update base for latest Safe Haskell.David Terei2011-10-251-0/+1
|
* SafeHaskell: Added SafeHaskell to baseDavid Terei2011-06-181-1/+2
|
* Big patch to improve Unicode support in GHC. Validated on OS X and Windows, thisMax Bolingbroke2011-05-141-42/+179
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | patch series fixes #5061, #1414, #3309, #3308, #3307, #4006 and #4855. The major changes are: 1) Make Foreign.C.String.*CString use the locale encoding This change follows the FFI specification in Haskell 98, which has never actually been implemented before. The functions exported from Foreign.C.String are partially-applied versions of those from GHC.Foreign, which allows the user to supply their own TextEncoding. We also introduce foreignEncoding as the name of the text encoding that follows the FFI appendix in that it transliterates encoding errors. 2) I also changed the code so that mkTextEncoding always tries the native-Haskell decoders in preference to those from iconv, even on non-Windows. The motivation here is simply that it is better for compatibility if we do this, and those are the ones you get for the utf* and latin1* predefined TextEncodings anyway. 3) Implement surrogate-byte error handling mode for TextEncoding This implements PEP383-like behaviour so that we are able to roundtrip byte strings through Strings without loss of information. The withFilePath function now uses this encoding to get to/from CStrings, so any code that uses that will get the right PEP383 behaviour automatically. 4) Implement three other coding failure modes: ignore, throw error, transliterate These mimic the behaviour of the GNU Iconv extensions.
* Use explicit language extensions & remove extension fields from base.cabalsimonpj@microsoft.com2011-01-281-0/+2
| | | | | | | | | | Add explicit {-# LANGUAGE xxx #-} pragmas to each module, that say what extensions that module uses. This makes it clearer where different extensions are used in the (large, variagated) base package. Now base.cabal doesn't need any extensions field Thanks to Bas van Dijk for doing all the work.
* Fix some "warn-unused-do-bind" warnings where we want to ignore the valueIan Lynagh2009-07-101-1/+2
|
* Remove unused imports from basesimonpj@microsoft.com2009-07-061-1/+1
| | | | | These unused imports are detected by the new unused-import code
* Rewrite of the IO library, including Unicode supportSimon Marlow2009-06-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Highlights: * Unicode support for Handle I/O: ** Automatic encoding and decoding using a per-Handle encoding. ** The encoding defaults to the locale encoding (only on Unix so far, perhaps Windows later). ** Built-in UTF-8, UTF-16 (BE/LE), and UTF-32 (BE/LE) codecs. ** iconv-based codec for other encodings on Unix * Modularity: the low-level IO interface is exposed as a type class (GHC.IO.IODevice) so you can build your own low-level IO providers and make Handles from them. * Newline translation: instead of being Windows-specific wired-in magic, the translation from \r\n -> \n and back again is available on all platforms and is configurable for reading/writing independently. Unicode-aware Handles ~~~~~~~~~~~~~~~~~~~~~ This is a significant restructuring of the Handle implementation with the primary goal of supporting Unicode character encodings. The only change to the existing behaviour is that by default, text IO is done in the prevailing locale encoding of the system (except on Windows [1]). Handles created by openBinaryFile use the Latin-1 encoding, as do Handles placed in binary mode using hSetBinaryMode. We provide a way to change the encoding for an existing Handle: GHC.IO.Handle.hSetEncoding :: Handle -> TextEncoding -> IO () and various encodings (from GHC.IO.Encoding): latin1, utf8, utf16, utf16le, utf16be, utf32, utf32le, utf32be, localeEncoding, and a way to lookup other encodings: GHC.IO.Encoding.mkTextEncoding :: String -> IO TextEncoding (it's system-dependent whether the requested encoding will be available). We may want to export these from somewhere more permanent; that's a topic for a future library proposal. Thanks to suggestions from Duncan Coutts, it's possible to call hSetEncoding even on buffered read Handles, and the right thing happens. So we can read from text streams that include multiple encodings, such as an HTTP response or email message, without having to turn buffering off (though there is a penalty for switching encodings on a buffered Handle, as the IO system has to do some re-decoding to figure out where it should start reading from again). If there is a decoding error, it is reported when an attempt is made to read the offending character from the Handle, as you would expect. Performance varies. For "hGetContents >>= putStr" I found the new library was faster on my x86_64 machine, but slower on an x86. On the whole I'd expect things to be a bit slower due to the extra decoding/encoding, but probabaly not noticeably. If performance is critical for your app, then you should be using bytestring and text anyway. [1] Note: locale encoding is not currently implemented on Windows due to the built-in Win32 APIs for encoding/decoding not being sufficient for our purposes. Ask me for details. Offers of help gratefully accepted. Newline Translation ~~~~~~~~~~~~~~~~~~~ In the old IO library, text-mode Handles on Windows had automatic translation from \r\n -> \n on input, and the opposite on output. It was implemented using the underlying CRT functions, which meant that there were certain odd restrictions, such as read/write text handles needing to be unbuffered, and seeking not working at all on text Handles. In the rewrite, newline translation is now implemented in the upper layers, as it needs to be since we have to perform Unicode decoding before newline translation. This means that it is now available on all platforms, which can be quite handy for writing portable code. For now, I have left the behaviour as it was, namely \r\n -> \n on Windows, and no translation on Unix. However, another reasonable default (similar to what Python does) would be to do \r\n -> \n on input, and convert to the platform-native representation (either \r\n or \n) on output. This is called universalNewlineMode (below). The API is as follows. (available from GHC.IO.Handle for now, again this is something we will probably want to try to get into System.IO at some point): -- | The representation of a newline in the external file or stream. data Newline = LF -- ^ "\n" | CRLF -- ^ "\r\n" deriving Eq -- | Specifies the translation, if any, of newline characters between -- internal Strings and the external file or stream. Haskell Strings -- are assumed to represent newlines with the '\n' character; the -- newline mode specifies how to translate '\n' on output, and what to -- translate into '\n' on input. data NewlineMode = NewlineMode { inputNL :: Newline, -- ^ the representation of newlines on input outputNL :: Newline -- ^ the representation of newlines on output } deriving Eq -- | The native newline representation for the current platform nativeNewline :: Newline -- | Map "\r\n" into "\n" on input, and "\n" to the native newline -- represetnation on output. This mode can be used on any platform, and -- works with text files using any newline convention. The downside is -- that @readFile a >>= writeFile b@ might yield a different file. universalNewlineMode :: NewlineMode universalNewlineMode = NewlineMode { inputNL = CRLF, outputNL = nativeNewline } -- | Use the native newline representation on both input and output nativeNewlineMode :: NewlineMode nativeNewlineMode = NewlineMode { inputNL = nativeNewline, outputNL = nativeNewline } -- | Do no newline translation at all. noNewlineTranslation :: NewlineMode noNewlineTranslation = NewlineMode { inputNL = LF, outputNL = LF } -- | Change the newline translation mode on the Handle. hSetNewlineMode :: Handle -> NewlineMode -> IO () IO Devices ~~~~~~~~~~ The major change here is that the implementation of the Handle operations is separated from the underlying IO device, using type classes. File descriptors are just one IO provider; I have also implemented memory-mapped files (good for random-access read/write) and a Handle that pipes output to a Chan (useful for testing code that writes to a Handle). New kinds of Handle can be implemented outside the base package, for instance someone could write bytestringToHandle. A Handle is made using mkFileHandle: -- | makes a new 'Handle' mkFileHandle :: (IODevice dev, BufferedIO dev, Typeable dev) => dev -- ^ the underlying IO device, which must support -- 'IODevice', 'BufferedIO' and 'Typeable' -> FilePath -- ^ a string describing the 'Handle', e.g. the file -- path for a file. Used in error messages. -> IOMode -- ^ The mode in which the 'Handle' is to be used -> Maybe TextEncoding -- ^ text encoding to use, if any -> NewlineMode -- ^ newline translation mode -> IO Handle This also means that someone can write a completely new IO implementation on Windows based on native Win32 HANDLEs, and distribute it as a separate package (I really hope somebody does this!). This restructuring isn't as radical as previous designs. I haven't made any attempt to make a separate binary I/O layer, for example (although hGetBuf/hPutBuf do bypass the text encoding and newline translation). The main goal here was to get Unicode support in, and to allow others to experiment with making new kinds of Handle. We could split up the layers further later. API changes and Module structure ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NB. GHC.IOBase and GHC.Handle are now DEPRECATED (they are still present, but are just re-exporting things from other modules now). For 6.12 we'll want to bump base to version 5 and add a base4-compat. For now I'm using #if __GLASGOW_HASKEL__ >= 611 to avoid deprecated warnings. I split modules into smaller parts in many places. For example, we now have GHC.IORef, GHC.MVar and GHC.IOArray containing the implementations of IORef, MVar and IOArray respectively. This was necessary for untangling dependencies, but it also makes things easier to follow. The new module structurue for the IO-relatied parts of the base package is: GHC.IO Implementation of the IO monad; unsafe*; throw/catch GHC.IO.IOMode The IOMode type GHC.IO.Buffer Buffers and operations on them GHC.IO.Device The IODevice and RawIO classes. GHC.IO.BufferedIO The BufferedIO class. GHC.IO.FD The FD type, with instances of IODevice, RawIO and BufferedIO. GHC.IO.Exception IO-related Exceptions GHC.IO.Encoding The TextEncoding type; built-in TextEncodings; mkTextEncoding GHC.IO.Encoding.Types GHC.IO.Encoding.Iconv GHC.IO.Encoding.Latin1 GHC.IO.Encoding.UTF8 GHC.IO.Encoding.UTF16 GHC.IO.Encoding.UTF32 Implementation internals for GHC.IO.Encoding GHC.IO.Handle The main API for GHC's Handle implementation, provides all the Handle operations + mkFileHandle + hSetEncoding. GHC.IO.Handle.Types GHC.IO.Handle.Internals GHC.IO.Handle.Text Implementation of Handles and operations. GHC.IO.Handle.FD Parts of the Handle API implemented by file-descriptors: openFile, stdin, stdout, stderr, fdToHandle etc.
* Add errno to the IOError typeIan Lynagh2009-01-041-1/+1
|
* split most of Control.Exception into new Control.Exception.BaseRoss Paterson2008-08-121-1/+1
| | | | | | | | | | | | | Move everything but catches/Handler into a new internal module. This was needed to get the new exceptions working with Hugs, because Hugs has the constraint that all Haskell 98 library modules, and everything they include, must be Haskell 98. This also involves a different representation of SomeException for Hugs, so that type is exported opaquely for Hugs. Then Control.Exception.Base is Haskell 98 as far as Hugs is concerned, but Control.Exception needs the extensions turned on. Control.Exception re-exports everything from Control.Exception.Base except the functions used by the GHC runtime.
* whitespace onlyDon Stewart2008-02-071-17/+17
|
* Fix C/Haskell type mismatchesIan Lynagh2007-04-031-2/+3
|
* [project @ 2005-01-28 15:03:06 by simonmar]simonmar2005-01-281-1/+0
| | | | Remove some unnecessary #includes of ghcconfig.h
* [project @ 2005-01-28 13:36:25 by simonmar]simonmar2005-01-281-1/+1
| | | | | | | Catch up with updates to platform #defines. Generally: use _HOST_ rather than _TARGET_ (except in Cabal where we have to retain compatibility with previous GHC versions).
* [project @ 2004-10-06 11:11:34 by ross]ross2004-10-061-0/+25
| | | | | Add getEnvironment from hslibs/lang/SystemExts. This differs from the System.Posix.Env version in not failing if an entry lacks an '=' sign.
* [project @ 2004-08-13 13:29:00 by simonmar]simonmar2004-08-131-1/+1
| | | | | Changes required be merge of backend-hacking-branch. Mostly config.h ==> ghcconfig.h.
* [project @ 2003-10-16 16:26:43 by ross]ross2003-10-161-3/+3
| | | | fix a couple of id references in haddock docs
* [project @ 2003-10-16 00:18:34 by ross]ross2003-10-161-6/+4
| | | | | | add withArgs and withProgName to Hugs. No change for GHC, but does change the docs, so please merge to STABLE.
* [project @ 2003-08-30 22:55:42 by ross]ross2003-08-301-6/+8
| | | | docs for System.Environment & System.Exit
* [project @ 2003-08-22 22:11:03 by sof]sof2003-08-221-0/+1
| | | | | | [GHC only]: Added missing 'config.h' #include ; needed by getProgName Merge to STABLE.
* [project @ 2003-08-05 17:24:40 by ross]ross2003-08-051-0/+3
| | | | add type signatures for Haddock's benefit
* [project @ 2003-05-12 10:16:22 by ross]ross2003-05-121-2/+3
| | | | documentation only: tag some things as "GHC only".
* [project @ 2002-12-13 13:36:36 by malcolm]malcolm2002-12-131-0/+2
| | | | Add #ifdef around import Control.Exception, which does not exist in nhc98.
View Lorry Controller Status