For example, command line history now works in the bash :)
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9721 a95241bf-73f2-0310-859d-f6bbb57e9c96
in the wrong direction for some time now, corrupting the argument area (user
apps would crash).
B_SYSTEM_TEAM is now reserved, so that no team can be created there.
Fixed some warnings when debug output is enabled.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9719 a95241bf-73f2-0310-859d-f6bbb57e9c96
Renamed console_reader() function to keyboard_reader().
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9718 a95241bf-73f2-0310-859d-f6bbb57e9c96
The inode now keeps track of the number of readers/writers.
Inode::BytesInChain() is now only used protected by the request lock.
Implemented some missing POSIX demands:
- when the last writer is closed, all waiting read requests are aborted
- pipefs_write() now returns EPIPE and signals the current thread with
SIGPIPE in case there are no readers left
- pipefs_read() will now return 0 in case there are no writers and no
unread buffers left in the pipe.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9717 a95241bf-73f2-0310-859d-f6bbb57e9c96
Correctly implemented devfs_create() - it will now open the an already
existing file if O_EXCL is not set, and no longer fail with EROFS.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9716 a95241bf-73f2-0310-859d-f6bbb57e9c96
divided into several parts, it could happen that overwrite the whole data
portion with data beyond the part that should have been read.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9706 a95241bf-73f2-0310-859d-f6bbb57e9c96
a comment that explains why the other TTY has to be chosen there.
Improved debug output.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9698 a95241bf-73f2-0310-859d-f6bbb57e9c96
was running. Thanks a lot to Jerome Duval who found this!
Since TTY ECHO mode doesn't look too well with the old shell, it will directly
start "sh" now, which should be the bash.
No longer prints out the TTY used when started, but now sets (as usually
done in BeOS) the TTY environment variable.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9697 a95241bf-73f2-0310-859d-f6bbb57e9c96
manager - note, this currently does not until the different module
APIs for file systems are merged together.
fs_mount_volume()'s order of arguments was changed.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9696 a95241bf-73f2-0310-859d-f6bbb57e9c96
Removed the fs_initialize_volume() function, as it's probably not going
to be needed.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9695 a95241bf-73f2-0310-859d-f6bbb57e9c96
there is no reason to let it appear important by having it as first
parameter; it's only used to override the DDM's decision if the user
so choses.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9694 a95241bf-73f2-0310-859d-f6bbb57e9c96
absolutely no reason to move them to B_SYSTEM_TEAM (additionally, during
startup, set_sem_owner() may crash).
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9693 a95241bf-73f2-0310-859d-f6bbb57e9c96
Changed the last argument of _kern_mount() to be a string rather than a void pointer.
Greatly reduced the stack usage of _user_mount(); it now uses KPath instead
of on stack paths. It now also copies the parameter argument on the heap.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9692 a95241bf-73f2-0310-859d-f6bbb57e9c96
and don't open foo again if it's running and we have files to give it.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9675 a95241bf-73f2-0310-859d-f6bbb57e9c96
the Spam Filter enables on any of his accounts does not seem to be a good way
to determine if we should show the Spam icon or not. Maybe we should check if
the Spam Server is available?
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9674 a95241bf-73f2-0310-859d-f6bbb57e9c96
To use this feature run StatCacheServer somewhere in the background.
The first run of jam will be slower, but subsequent ones will usually
benefit. Only little, if the BeOS FS cache is able to hold the data,
but as soon as the number of files and directories jam has to inspect
hits the limit at which the cache drops data needed for the next run,
the performance difference will be very noticeable.
E.g. the time for a "jam -n > /dev/null" in the root of a partially built
tree on my machine dropped from >1 min without the server to 13 secs
with it (not in the first run, of course).
Although tested quite a bit, I would still consider the feature
experimental.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9671 a95241bf-73f2-0310-859d-f6bbb57e9c96